aboutsummaryrefslogtreecommitdiff
path: root/pipermail/nel/2001-February/000230.html
diff options
context:
space:
mode:
Diffstat (limited to 'pipermail/nel/2001-February/000230.html')
-rw-r--r--pipermail/nel/2001-February/000230.html96
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:
+&gt;<i> On Mon, Feb 19, 2001 at 03:43:59PM -0600, Jared Mark wrote:
+</I>&gt;<i> &gt; Okay, so what you're saying is basically this...
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; By seperating the services, you can have a cluster of machines, each running
+</I>&gt;<i> &gt; different services, and thus, keeping the load down across the board. You
+</I>&gt;<i> &gt; would have a single system, for example, handling just combat resolution,
+</I>&gt;<i> &gt; 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.
+
+&gt;<i> We may have to add features concerning high-availability, as this scheme
+</I>&gt;<i> doesn't allow it : if the computing holding the combat resolution fails, the
+</I>&gt;<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.
+
+&gt;<i> The second point is that if a service grow too much, the load-balancing won't
+</I>&gt;<i> respond to the problem. You mentionned this point in your previous mail I
+</I>&gt;<i> think.
+</I>&gt;<i>
+</I>&gt;<i> One possible architecture is to write separate process, and give two or three
+</I>&gt;<i> computer the responsiblity to distribute, by monitoring the farm, those
+</I>&gt;<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>