Score-Based Dynamic Load Balancer (SBDLB)
- Score-Based Dynamic Load Balancer (SBDLB) is a VM-level policy that computes an additive suitability score from real-time CPU/MIPS, RAM, and bandwidth metrics.
- It outperforms throttled load balancing by improving average response time by up to 37% and reducing data center processing time and operational cost.
- The mechanism reacts to instantaneous workload fluctuations by enforcing concurrency thresholds and excluding overloaded VMs, ensuring efficient task routing.
The Score-Based Dynamic Load Balancer (SBDLB) is a VM-level load balancing policy for cloud infrastructure that assigns each incoming task to the “best” virtual machine by computing a numeric score from real-time resource availability and a task-specific concurrency threshold. In its canonical formulation, SBDLB continuously monitors each VM’s free CPU/MIPS, RAM, and bandwidth; normalizes task demand to the current resource scale of each VM; excludes infeasible or overly busy VMs; and assigns the task to the candidate with the highest score. In CloudSim 7G evaluation against the throttled load balancing strategy, the method improved average response time by 34% and 37% in different scenarios, reduced data center processing time by an average of 13%, and lowered 24-hour operational cost by 15.02%, with the cost reduction presented as a proxy for lower energy consumption (Sakib et al., 7 Aug 2025).
1. Conceptual basis and motivation
SBDLB is designed for heterogeneous, bursty cloud environments in which a binary available/not-available dispatch rule is too coarse. The central contrast in the originating work is with the throttled load balancing strategy, which maintains a pool of VMs, assigns each task to the first “available” VM, and does not account for heterogeneous VM capacities or the task’s actual resource consumption beyond a binary availability decision. The limitations identified for throttled load balancing are no fine-grained resource awareness, poor handling of heterogeneity, and static behavior with only coarse adaptation to instantaneous load (Sakib et al., 7 Aug 2025).
Within that framing, SBDLB is a dynamic and metric-based policy. Its suitability measure is recomputed on every task arrival from the current VM state, so routing decisions react to workload fluctuations rather than to static configuration alone. The paper explicitly motivates this design by reference to bursty and diurnal workloads, heterogeneous infrastructure, QoS-sensitive cloud services, and the linkage between faster workload completion and lower energy or operational cost (Sakib et al., 7 Aug 2025).
The broader idea of collapsing multi-resource state into a scalar dispatch criterion predates the specific SBDLB formulation. A related distributed-systems load balancing algorithm defines a composite server metric over CPU, memory, and network state and selects the server with the smallest scalar value, while also introducing integrated imbalance metrics such as and (Kirichenko et al., 2019). This establishes that SBDLB belongs to a wider class of score-based dispatchers, although the concrete scoring rule, monitoring cadence, and optimization target differ across implementations.
2. System model, resources, and workload assumptions
The reference SBDLB system model mirrors an IaaS cloud provider with multiple geographically distributed data centers,
each hosting hundreds of physical machines. Two host types are modeled: Type 1 with 4 cores, 1 GB RAM, 10 GB storage, and 1000 MB/s bandwidth, and Type 2 with 8 cores, 2 GB RAM, 20 GB storage, and 2000 MB/s bandwidth. VM heterogeneity is explicit as well: low-spec VMs provide 500 MIPS, 1 GB RAM, 10 GB storage, 1000 MB/s, and 1 core, while high-spec VMs provide 1000 MIPS, 2 GB RAM, 20 GB storage, 2000 MB/s, and 2 cores. End-user requests are modeled as CloudSim cloudlets that are routed by the data center broker through the load balancer to VMs (Sakib et al., 7 Aug 2025).
The network model follows CloudSim’s default assumptions. Inter-data-center latency is abstracted because the emphasis is VM-level load balancing, while network heterogeneity is represented through bandwidth capacities. SLA or QoS constraints are not encoded as hard deadlines; instead, they are represented indirectly by response time, data center processing time, and operational cost. CloudSim’s internal time-shared space-shared CPU scheduling handles intra-VM scheduling (Sakib et al., 7 Aug 2025).
The workload is social-media-like. Tasks are divided into Reels, Images, and Text posts, with data-size ranges of 10 MB–1 GB, 1–30 MB, and 10–100 KB, respectively. Their distribution is 60% Reels, 30% Images, and 10% Text, with different computational intensities used to convert data size into MI. Arrivals are batched, and batch sizes and counts vary by hour to emulate peak and non-peak periods. Peak hours are 8–10, 13–14, and 17–22, with batch sizes 5K, 5.5K, and 6K, randomly chosen, and 18–20 batches per hour. Non-peak hours use batch sizes 3K, 3.5K, and 4K with 9–11 batches per hour (Sakib et al., 7 Aug 2025).
3. Scoring mechanism and execution flow
The defining feature of SBDLB is the translation of multi-resource feasibility into a single additive suitability score. Task demand is first normalized by min–max scaling,
with the output mapped to the resource scale of each VM’s available MIPS, RAM, and bandwidth. The paper states that task length is normalized into a range compatible with availableMIPS, availableRAM, and availableBW, so feasibility is checked in all three resource dimensions for each VM (Sakib et al., 7 Aug 2025).
For any VM that passes feasibility, the suitability score is
If a VM cannot satisfy the normalized CPU, RAM, or bandwidth demand of the task, it is assigned
which removes it from consideration. The scoring rule is explicitly simple, additive, and unweighted: the design does not introduce coefficients such as , and all three dimensions contribute equally in raw units (Sakib et al., 7 Aug 2025).
To prevent overload from many small tasks, the algorithm imposes a maximum number of concurrent tasks per VM. Empirical testing over 1–8 data centers, 2000 tasks in 250 batches, and thresholds 2, 3, 4, and 5 found that a threshold of 3 active tasks per VM was best: it performed as well as threshold 4, achieved lower response time than threshold 2, and avoided the overload observed with threshold 5 in small setups. Only VMs with activeTaskCount < threshold remain in the candidate set (Sakib et al., 7 Aug 2025).
The high-level decision procedure is reactive and instantaneous. For each incoming task, SBDLB enumerates all VMs, excludes those at or above the threshold, retrieves current availableMIPS, availableRAM, and availableBW, normalizes task demand, checks feasibility, computes scores, and selects the VM with maximum score. Ties may be broken arbitrarily or by VM ID. If no VM has Score \ge 0, the task is queued until a VM completes work and frees resources; upon completion, resource availability is updated and waiting tasks are re-evaluated. Scores are recomputed on every task arrival, and the paper explicitly notes that there is no history-based or predictive component such as moving averages or trend analysis (Sakib et al., 7 Aug 2025).
A common misconception is that SBDLB performs dynamic reallocation of running work. It does not. The paper states that it does not implement VM migration, dynamic reassignment of already running tasks, or autoscaling. Adaptation occurs only in routing new tasks under current resource state (Sakib et al., 7 Aug 2025).
4. Empirical evaluation in CloudSim 7G
The evaluation uses CloudSim 7G, with up to 8 data centers, two VM types, and usually 60 VMs per data center, which the study identifies as a “sweet spot.” Scenario design varies VM count, data center count, task allocation patterns on heterogeneous VMs, and 24-hour diurnal workloads (Sakib et al., 7 Aug 2025).
| Scenario | Configuration | Main result |
|---|---|---|
| VM scalability | 8 DCs, 10–80 VMs/DC, up to 500K tasks | 34% lower average response time at 500K tasks; |
| Varying DCs | 1–8 DCs, 60 VMs/DC, up to 500K tasks | 37% lower average response time; ; 13% average reduction in data center processing time; |
| Task allocation | Heterogeneous low/high-spec VMs | Greater proportion of tasks assigned to high-spec VMs; throttled distributes more uniformly |
| 24-hour variation | Peak and non-peak hourly batches | SBDLB cost \$IBL_{avg}^{SYS}$026,246; 15.02% operational-cost reduction |
The VM-scalability scenario shows a sharp response-time improvement as VM count increases toward about 60 VMs per data center, after which gains plateau. The varying-data-center scenario shows that SBDLB can match or beat throttled with fewer data centers, with the paper giving the example of three data centers for SBDLB versus four for throttled. The heterogeneous-allocation scenario is important because it makes the mechanism visually interpretable: SBDLB produces crests in high-spec VM task counts and troughs in low-spec VM task counts, whereas throttled uses the VM set more uniformly and thereby overuses low-spec machines while underutilizing high-spec machines. The 24-hour scenario reports consistently lower hourly average response times and lower hourly data center processing times throughout peak and non-peak periods (Sakib et al., 7 Aug 2025).
The paper treats operational cost as proportional to processing time and per-second CPU cost. It does not provide an explicit power model such as $IBL_{avg}^{SYS}$1, but argues that shorter data center processing time implies that servers and VMs can enter low-power or idle states sooner. On that basis, the reported 15.02% cost reduction is presented as strong evidence of reduced energy consumption and improved sustainability (Sakib et al., 7 Aug 2025).
5. Relation to adjacent score-based and dynamic load-balancing research
The SBDLB formulation in cloud infrastructure is one instance of a broader research pattern in which resource state is compressed into a scalar decision variable. In distributed systems, one dynamic load balancing algorithm continuously monitors CPU, RAM, and network utilization, analyzes the self-similar or multifractal properties of traffic via the generalized Hurst exponent, adapts monitoring frequency according to $IBL_{avg}^{SYS}$2, and computes a composite metric $IBL_{avg}^{SYS}$3 for server selection. That work also defines integrated imbalance metrics such as $IBL_{avg}^{SYS}$4, $IBL_{avg}^{SYS}$5, and $IBL_{avg}^{SYS}$6, which formalize cluster-wide balance quality rather than only per-request routing choice (Kirichenko et al., 2019).
A distinct but closely related design appears in Adaptive Weighted Least-Connection scheduling for heterogeneous mobile-code offloading. There, the effective host score is the ratio between complexity-weighted load and a dynamic capacity score based on CPU idle and memory idle,
$IBL_{avg}^{SYS}$7
and the selected host is the one with minimum score. In CloudSim experiments with 150, 1500, and 15000 tasks, that approach outperformed Least-Connections and static Weighted Least-Connections in both mean completion time and standard deviation of completion time across hosts (Jungum et al., 2020).
A more formalized policy-language perspective appears in work on performance- and energy-aware load balancing. There, the load balancer evaluates a per-server policy expression and chooses the server with the highest value of that expression. The policy grammar exposes queue size, power state, power draw, transition times, timeout, random tie-breaking, and design-space parameters. The concrete family
$IBL_{avg}^{SYS}$8
shows how a score can encode a performance–energy trade-off by penalizing sleeping servers until queue growth justifies wakeup cost (Berg et al., 2016).
At Layer 4, KNAPSACKLB generalizes score-based balancing in yet another direction. It measures per-backend application latency through active probes, learns a weight-to-latency curve for each backend, and solves an ILP over binary variables $IBL_{avg}^{SYS}$9 to assign weights that minimize total average latency. In experiments, it reduced average latency by up to 45% relative to existing designs while remaining generic across multiple LB implementations (Gandhi et al., 2024).
Taken together, these systems indicate that “score-based” does not identify a single algorithmic family but a design principle: dispatch is driven by a scalar ranking derived from measured or estimated system state. The principal differences lie in what is scored—available resources, current load, power state, predicted latency, or queue length—and in whether the score is reactive, predictive, thresholded, or optimization-derived.
6. Limitations, misconceptions, and future directions
The canonical SBDLB is deliberately narrow in scope. It is reactive rather than predictive, single-objective rather than explicitly multi-objective, and confined to new-task routing rather than migration or elastic resizing. The paper also notes that equal weighting of CPU, RAM, and bandwidth in raw units may not be optimal for all workloads, especially when workload classes differ sharply in whether they are CPU-bound or I/O-bound. SLA and QoS are not modeled as explicit hard constraints, and the energy argument is indirect because operational cost and active time are used as proxies rather than an explicit power model (Sakib et al., 7 Aug 2025).
This also clarifies a second misconception: SBDLB is not synonymous with any dynamic thresholding system. Large-scale service systems have been studied with self-learning threshold-based dispatch, where the dispatcher adjusts a threshold online, proves fluid- and diffusion-scale optimality, and requires only small communication overhead through a token mechanism. That line of work is score-like in its use of a learned global threshold, but its state abstraction, asymptotic regime, and objective differ from VM-level additive resource scoring (Goldsztajn et al., 2020).
A third distinction concerns dynamic rebalancing in stateful streaming systems. In actor-based data-parallel systems, load balancers have been built around reducer queue length as the load score, with consistent hashing, input forwarding, and a final state-merge step to preserve correctness after redistribution. Those systems target skew-induced stragglers and rely on queue-length imbalance criteria such as
0
rather than on real-time VM resource availability (Wang et al., 2023).
Future directions stated for SBDLB include reinforcement learning or machine learning for more sophisticated scoring functions and dynamic thresholds, broader scalability studies with richer heterogeneity, explicit multi-objective optimization across latency, SLA violations, energy consumption, and cost, integration with green scheduling and carbon-aware resource management, and extension from VM placement to container orchestration. A plausible implication is that later score-based systems may increasingly separate control-plane intelligence from dataplane execution, as already seen in FPGA-assisted transport load balancing where telemetry-driven control planes compute weighted calendars that the data plane enforces at line rate (Sakib et al., 7 Aug 2025, Sheldon et al., 2023).
