From 0ea5fc66924303d1bf73ba283a383e2aadee02f2 Mon Sep 17 00:00:00 2001 From: neodarz Date: Sat, 11 Aug 2018 20:21:34 +0200 Subject: Initial commit --- pipermail/nel/2001-February/000229.html | 78 +++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 pipermail/nel/2001-February/000229.html (limited to 'pipermail/nel/2001-February/000229.html') diff --git a/pipermail/nel/2001-February/000229.html b/pipermail/nel/2001-February/000229.html new file mode 100644 index 00000000..eafe2459 --- /dev/null +++ b/pipermail/nel/2001-February/000229.html @@ -0,0 +1,78 @@ + + + + [Nel] Dynamic load balancing? + + + + + + +

[Nel] Dynamic load balancing?

+ Thierry Mallard + thierry@mallard.com
+ Tue, 20 Feb 2001 10:56:54 +0100 +

+
+ +
On Mon, Feb 19, 2001 at 03:43:59PM -0600, Jared Mark wrote:
+> Okay, so what you're saying is basically this...
+> 
+> By seperating the services, you can have a cluster of machines, each running
+> different services, and thus, keeping the load down across the board.  You
+> would have a single system, for example, handling just combat resolution,
+> and you would have another system that would keep track of the database...
+
+We may have to add features concerning high-availability, as this scheme
+doesn't allow it : if the computing holding the combat resolution fails, the
+world will be a heaven of peace  ;-)
+
+The second point is that if a service grow too much, the load-balancing won't
+respond to the problem. You mentionned this point in your previous mail I
+think.
+
+One possible architecture is to write separate process, and give two or three
+computer the responsiblity to distribute, by monitoring the farm, those
+process. I dunno if such scheme is possible w.r.t. the current NeL objectives
+(?)
+
+Best regards,
+
+	Shaman
+
+-- 
+Thierry Mallard              |              
+GnuPG key on wwwkeys.pgp.net |
+key 0xA3D021CB               |
+http://thierry.mallard.com   |     
+
+
+
+ + + + + +
+

+ -- cgit v1.2.1