---
title: Score-Based Dynamic Load Balancer (SBDLB)
url: https://www.emergentmind.com/topics/score-based-dynamic-load-balancer-sbdlb
type: topic
---

# Score-Based Dynamic Load Balancer (SBDLB)

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 [2508.05821].

## 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 [2508.05821].

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 [2508.05821].

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 \(ILB_i\) and \(IBL_{avg}^{SYS}\) [1904.09227]. 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,
\[
DC = \{DC_1, DC_2, \dots, DC_d\},
\]
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 [2508.05821].

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 [2508.05821].

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 [2508.05821].

## 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,
\[
y = \frac{(x - x_{\min})}{(x_{\max} - x_{\min})} \times (y_{\max} - y_{\min}) + y_{\min},
\]
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 [2508.05821].

For any VM that passes feasibility, the suitability score is
\[
\text{Score} = \text{availableMIPS} + \text{availableRAM} + \text{availableBW}.
\]
If a VM cannot satisfy the normalized CPU, RAM, or bandwidth demand of the task, it is assigned
\[
\text{Score} = -1,
\]
which removes it from consideration. The scoring rule is explicitly simple, additive, and unweighted: the design does not introduce coefficients such as \(w_1,w_2,w_3\), and all three dimensions contribute equally in raw units [2508.05821].

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 [2508.05821].

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 [2508.05821].

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 [2508.05821].

## 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 [2508.05821].

| Scenario | Configuration | Main result |
|---|---|---|
| VM scalability | 8 DCs, 10–80 VMs/DC, up to 500K tasks | 34% lower average response time at 500K tasks; \(p = 3.54 \times 10^{-10}\) |
| Varying DCs | 1–8 DCs, 60 VMs/DC, up to 500K tasks | 37% lower average response time; \(p = 3.35 \times 10^{-12}\); 13% average reduction in data center processing time; \(p = 4.48 \times 10^{-9}\) |
| 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 \$22,818 vs throttled \$26,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 [2508.05821].

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 \(P(u)=P_{\text{idle}}+(P_{\max}-P_{\text{idle}})u\), 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 [2508.05821].

## 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 \(\Delta h\), and computes a composite metric \(B_i\) for server selection. That work also defines integrated imbalance metrics such as \(ILB_i\), \(IBL_{CPU}\), and \(IBL_{avg}^{SYS}\), which formalize cluster-wide balance quality rather than only per-request routing choice [1904.09227].

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,
\[
\text{Score}(S_i)=\frac{\sum_{j=1}^{4} C_{ij}P_j}{3V_c(S_i)+2V_m(S_i)},
\]
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 [2008.12385].

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
\[
\mathcal{P}_q=-queueSize-q\cdot(1-stateOn)
\]
shows how a score can encode a performance–energy trade-off by penalizing sleeping servers until queue growth justifies wakeup cost [1610.08172].

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 \(X_{d,w}\) 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 [2404.17783].

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 [2508.05821].

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 [2010.15525].

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
\[
Q_{\max} > Q_s(1+\tau),
\]
rather than on real-time VM resource availability [2308.00938].

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 [2508.05821; 2303.16351].

Source: https://www.emergentmind.com/topics/score-based-dynamic-load-balancer-sbdlb