Fast and Cost-Effective Online Load-Balancing in - Computing ...
Fast and Cost-Effective Online Load-Balancing in - Computing ...
Fast and Cost-Effective Online Load-Balancing in - Computing ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
KONSTANTINOU ET AL.: FAST AND COST-EFFECTIVE ONLINE LOAD-BALANCING IN DISTRIBUTED RANGE-QUERIABLE SYSTEMS 1359<br />
Fig. 10. Completion time, exchanged messages <strong>and</strong> items <strong>and</strong> MIG to NIX ratio of NIXMIG <strong>and</strong> Item <strong>Balanc<strong>in</strong>g</strong> for various zipfian values.<br />
<strong>and</strong> MIG. In addition, NIXMIG requires less than half the<br />
messages compared to IB: IB requires a large number of<br />
prob<strong>in</strong>g messages, whereas NIXMIG uses the underloaded<br />
node location mechanism described <strong>in</strong> Section 4. Furthermore,<br />
the number of required messages <strong>in</strong> the IB algorithm<br />
<strong>in</strong>creases more due to the fact that mostly node migrations<br />
are performed, as its MIG to NIX ratio is near 0.5 (see the<br />
fourth graph).<br />
In the third graph, we notice that NIX requires two<br />
orders of magnitude more item exchanges than MIG <strong>and</strong><br />
NIXMIG due to the iterative key transfer procedure. What is<br />
more, NIXMIG requires roughly the same number of item<br />
exchanges compared to MIG. NIXMIG outperforms IB<br />
whereas <strong>in</strong> skewed workloads NIXMIG exchanges one<br />
third of the items compared to IB: the cooperative nature of<br />
NIXMIG m<strong>in</strong>imizes unnecessary load movement (thus item<br />
exchanges) back <strong>and</strong> forth, unlike IB where each node acts<br />
on its own. We observe that the IB’s number of exchanged<br />
messages <strong>and</strong> items drops when the workload is less<br />
skewed: IB performs less balanc<strong>in</strong>g actions, as it cannot<br />
easily locate nodes that their load differs by a fraction of ".<br />
F<strong>in</strong>ally, <strong>in</strong> the fourth graph, we present NIXMIG’s <strong>and</strong><br />
IB’s ratio of migrations to simple neighbor<strong>in</strong>g item<br />
exchange operations for various pulse widths. Here, we<br />
notice NIXMIG’s workload adaptivity: <strong>in</strong> extremely skewed<br />
workloads of 3-5 percent pulse widths mostly node<br />
migrations are used (recall from Algorithm 2 that each<br />
migration requires two neighbor<strong>in</strong>g item exchanges, thus<br />
the ratio <strong>in</strong> pla<strong>in</strong> migrations is 0.5). When the pulse’s width<br />
is <strong>in</strong>creased, the ratio drops as load is absorbed us<strong>in</strong>g more<br />
neighbor<strong>in</strong>g item exchanges <strong>and</strong> costly remote migrations<br />
are avoided. On the contrary, IB most of the times carelessly<br />
employs node migrations.<br />
These experiments confirm NIXMIG’s adaptivity to an<br />
arbitrary workload, as it identifies the most effective<br />
balanc<strong>in</strong>g action, comb<strong>in</strong><strong>in</strong>g the advantages <strong>and</strong> avoid<strong>in</strong>g<br />
the disadvantages of both pla<strong>in</strong> remote migrations <strong>and</strong><br />
pla<strong>in</strong> neighbor<strong>in</strong>g item exchanges. We cont<strong>in</strong>ue our experimental<br />
analysis with a more thorough comparison of<br />
NIXMIG aga<strong>in</strong>st IB.<br />
In Fig. 11, we present a system’s load snapshot after<br />
100 seconds for the two algorithms for a 3 percent pulse. We<br />
notice that, unlike IB (dotted l<strong>in</strong>e), NIXMIG (solid l<strong>in</strong>e) has<br />
successfully dropped almost every node’s load under its<br />
thres value (horizontal red l<strong>in</strong>e). Moreover, <strong>in</strong> Fig. 12, we<br />
present the variation of exchanged messages dur<strong>in</strong>g time<br />
for the NIXMIG <strong>and</strong> the IB algorithm. We notice that<br />
NIXMIG constantly performs less message exchanges than<br />
IB. What is more, <strong>in</strong> the IB algorithm, we notice the constant<br />
traffic posed by the r<strong>and</strong>om prob<strong>in</strong>g messages.<br />
In Fig. 10, we present the performance results of NIXMIG<br />
aga<strong>in</strong>st IB for the zipfian sett<strong>in</strong>g. In this situation, the<br />
workload’s skew <strong>in</strong>creases as the parameter <strong>in</strong>creases<br />
unlike the pulse sett<strong>in</strong>g where the skew decreases as the<br />
pulse width <strong>in</strong>creases. In the first graph, we notice that<br />
NIXMIG’s completion time is similar to the one <strong>in</strong> the pulse<br />
sett<strong>in</strong>g. On the other h<strong>and</strong>, IB’s completion time <strong>in</strong>creases<br />
compared to the respective completion time for the pulse<br />
sett<strong>in</strong>g: <strong>in</strong> the zipfian case, the load is spread more<br />
uniformly compared to the pulse sett<strong>in</strong>g, mak<strong>in</strong>g it harder<br />
for IB to identify load imbalances. In any case, NIXMIG is<br />
three times faster than IB. In the second graph, we notice<br />
that NIXMIG requires a constant number of messages with<br />
a slight drop <strong>in</strong> the less skewed workload area, as more<br />
neighbor<strong>in</strong>g item exchanges are performed. On the other<br />
h<strong>and</strong>, IB requires constantly more messages due to the<br />
reasons mentioned <strong>in</strong> the previous paragraph. In the<br />
workloads with >3, NIXMIG requires one sixth of<br />
the messages that IB requires. In the third graph, we<br />
observe that NIXMIG’s <strong>and</strong> IB’s behavior <strong>in</strong> item exchanges<br />
is similar as <strong>in</strong> the pulse sett<strong>in</strong>g. NIXMIG performs more<br />
item exchanges than IB <strong>in</strong> the less skewed workloads of<br />
Fig. 11. <strong>Load</strong> snapshot at t ¼ 800 sec for a 3 percent pulse.<br />
Fig. 12. Number of exchanged messages dur<strong>in</strong>g time for a 3 percent<br />
pulse.