diff options
| author | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
|---|---|---|
| committer | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
| commit | 0ea5fc66924303d1bf73ba283a383e2aadee02f2 (patch) | |
| tree | 2568e71a7ccc44ec23b8bb3f0ff97fb6bf2ed709 /pipermail/nel/2001-February/000230.html | |
| download | nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.tar.xz nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.zip | |
Initial commit
Diffstat (limited to 'pipermail/nel/2001-February/000230.html')
| -rw-r--r-- | pipermail/nel/2001-February/000230.html | 96 |
1 files changed, 96 insertions, 0 deletions
diff --git a/pipermail/nel/2001-February/000230.html b/pipermail/nel/2001-February/000230.html new file mode 100644 index 00000000..d7b56776 --- /dev/null +++ b/pipermail/nel/2001-February/000230.html @@ -0,0 +1,96 @@ +<!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="000229.html"> + <LINK REL="Next" HREF="000233.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>Tue, 20 Feb 2001 14:20:32 +0100</I> + <P><UL> + <LI> Previous message: <A HREF="000229.html">[Nel] Dynamic load balancing?</A></li> + <LI> Next message: <A HREF="000233.html">[Nel] Dynamic load balancing?</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#230">[ date ]</a> + <a href="thread.html#230">[ thread ]</a> + <a href="subject.html#230">[ subject ]</a> + <a href="author.html#230">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>According to Thierry Mallard: +><i> On Mon, Feb 19, 2001 at 03:43:59PM -0600, Jared Mark wrote: +</I>><i> > Okay, so what you're saying is basically this... +</I>><i> > +</I>><i> > By seperating the services, you can have a cluster of machines, each running +</I>><i> > different services, and thus, keeping the load down across the board. You +</I>><i> > would have a single system, for example, handling just combat resolution, +</I>><i> > and you would have another system that would keep track of the database... +</I> +Basically, yes. It may be more complicated than this. For example, we must +strive to keep only a single service handling items, while we may run +multiple concurrent instances of AI services to have lots of smart bots. + +><i> We may have to add features concerning high-availability, as this scheme +</I>><i> doesn't allow it : if the computing holding the combat resolution fails, the +</I>><i> world will be a heaven of peace ;-) +</I> +It's all a compromise. If a geographic server (in a geographic approach) +fails, suddendly, part of the world becomes unpassable. You can't log in +if you were in them, you can't enter them, and so on. Different failure +modes. + +><i> The second point is that if a service grow too much, the load-balancing won't +</I>><i> respond to the problem. You mentionned this point in your previous mail I +</I>><i> think. +</I>><i> +</I>><i> One possible architecture is to write separate process, and give two or three +</I>><i> computer the responsiblity to distribute, by monitoring the farm, those +</I>><i> process. I dunno if such scheme is possible w.r.t. the current NeL objectives +</I> +It is. In fact, a lot of services will be spread across different nodes, +but that's because these services are 'linear': each agent it manages +deals chiefly with itself. On the other hand, some are harder to split. +Item management for example, because of ownership and transfer issues: +if item A is owner by entity E, and all items of entity E are on server S1, +what happens when item is given to entity D, whose items are all on the +server S2. You break locality, which defeats the purpose of functional +services. + +However, for load balancing purpose, one feature of functional split is +quite simple. If your item server, for example, manages 300,000 currently +present items, it doesn't matter if everyone currently on-line decides +to cluster in a single city: there are still 300,000 items to manage, and +the amount of item interactions haven't changed much. + +-- +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="000229.html">[Nel] Dynamic load balancing?</A></li> + <LI> Next message: <A HREF="000233.html">[Nel] Dynamic load balancing?</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#230">[ date ]</a> + <a href="thread.html#230">[ thread ]</a> + <a href="subject.html#230">[ subject ]</a> + <a href="author.html#230">[ author ]</a> + </LI> + </UL> +</body></html> |