diff options
Diffstat (limited to 'pipermail/nel/2001-February/000212.html')
| -rw-r--r-- | pipermail/nel/2001-February/000212.html | 82 |
1 files changed, 82 insertions, 0 deletions
diff --git a/pipermail/nel/2001-February/000212.html b/pipermail/nel/2001-February/000212.html new file mode 100644 index 00000000..2b9cec97 --- /dev/null +++ b/pipermail/nel/2001-February/000212.html @@ -0,0 +1,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: +><i> I would love dynamic load balancing... just add another server to your +</I>><i> cluster, and assign it a piece of the game world to take care of... perhaps +</I>><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 "pressure". 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> |