aboutsummaryrefslogtreecommitdiff
path: root/pipermail/nel/2001-February/000212.html
blob: 2b9cec97027de4cb9cbf015f41ca73bb3b142270 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [Nel] Dynamic load balancing?</TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:archer%40nevrax.com">
   <LINK REL="Previous"  HREF="000209.html">
   <LINK REL="Next" HREF="000213.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[Nel] Dynamic load balancing?</H1>
    <B>Vincent Archer</B> 
    <A HREF="mailto:archer%40nevrax.com"
       TITLE="[Nel] Dynamic load balancing?">archer@nevrax.com</A><BR>
    <I>Mon, 19 Feb 2001 17:04:15 +0100</I>
    <P><UL>
        <LI> Previous message: <A HREF="000209.html">[Nel] Dynamic load balancing?</A></li>
        <LI> Next message: <A HREF="000213.html">[Nel] Dynamic load balancing?</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#212">[ date ]</a>
              <a href="thread.html#212">[ thread ]</a>
              <a href="subject.html#212">[ subject ]</a>
              <a href="author.html#212">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>According to EagleEye:
&gt;<i> I would love dynamic load balancing... just add another server to your
</I>&gt;<i> cluster, and assign it a piece of the game world to take care of... perhaps
</I>&gt;<i> that city area that just got really popular in the last few weeks...
</I>
That's not dynamic load balancing if you have to assign servers to a
specific area. That's merely 'reconfigurable static' :)

Ultima Online did this for their servers. They measured during beta
a lot of statistics, and created a map of areas for allocation to all
processors (server being ambiguous here, because their servers were
multiprocessor boxes). That map could be redone at will, depending on
the number of processors allocated to a shard. But once the shard was
started, that was it. The only way to add a processor would be to
split one area in two, and the whole migration process was hard
enough that it wasn't worth (their words) the development cost vs the
number of times it would be used.

True dynamic load would mean that each processor would adjust its
border (i.e. which objets it manages) according to its load, compared to
its neighbours. If it has too high a load, then its border would shrink
along its most lightly loaded neighbour, swapping objects between one
and the other.

Of course, that means a variable, almost fractal geometry of processors,
and a processor that, at boot time, was serving city A and its adjacent
areas could well, four days later, be serving chiefly the mountain range
5km from there, because of simple &quot;pressure&quot;. It looks nice from a
strict research standpoint, but it's HELL for system management.

-- 
Vincent Archer                                         Email: <A HREF="mailto:archer@nevrax.com">archer@nevrax.com</A>

Nevrax France.                              Off on the yellow brick road we go!

</pre>





<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI> Previous message: <A HREF="000209.html">[Nel] Dynamic load balancing?</A></li>
	<LI> Next message: <A HREF="000213.html">[Nel] Dynamic load balancing?</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#212">[ date ]</a>
              <a href="thread.html#212">[ thread ]</a>
              <a href="subject.html#212">[ subject ]</a>
              <a href="author.html#212">[ author ]</a>
         </LI>
       </UL>
</body></html>