Regionalized zone servers vs. regionalized caches.

The first of two articles I posted on Philip's weblog -- this one is about geographic regionalization of zone servers.
Philip, this idea of moving servers to closer geographic proximity of subscribers is ill-founded and will impact on your ability to scale, except in the sole case of caches. The issue are nothing like those in geographic distribution of web servers or of MMOG universes where a player's server set does not interact with others.

In doing so, you are somewhat hardwiring in the concept of static server allocation, and making it even worse by tying servers to zones to 1L geography. You reduce your ability to aggregate servers into dynamic pools, because a box in a European cluster will never be able to be aggregated dynamically into a US cluster. (It can be done, but the performance is poor.)

Even worse though, it misses the key point that where you need most server power is at events, not in your home zone (except coincidentally). Geographic proximity does not help at all unless you are trying to promote regionalized separation of events and nationalism, which would be so utterly appalling that I cannot believe it to be the case.

I would examine this idea more closely before you put it into effect. At some point SL will grow so huge that the object-serving pools will need to be split into sub-pools with streaming caches between them, and at that point you might as well consider geographic separation, but that is a long way off.

[Posted on weblog by: Morgaine Dinova | October 30, 2004 04:12 PM]

And this one is on geographic regionalization of caching servers:

I mentioned regionalized caches, but said nothing about them, so here goes.

If a system employs caching servers, it always makes sense to regionalize them when there are long-lived objects in the world that can be cached and when the client experience is strongly RTT-sensitive. That follows from the standard benefits of caches, namely reduced loading on the master servers and faster perceived response to the client. Ie. it goes without saying.

Currently the client has a problem in that a single thread is used for both rendering and networking, which couples the two tasks and must affect both very adversely. No doubt this is being addressed, since Lindens have mentioned this on the forums. Even then however, client-server RTTs will continue to affect player experience very strongly, and therefore regionalized object caches always make sense.

Unfortunately, there is a related issue that would totally undermine the ability of regionalized caches to do their job well, just as it undermines the ability of client caches to do their jobs well right now. That issue is the "dirtying" of objects (from the point of view of invalidating cache entries) by scripts, and the contamination of this dirty status to the entire link set of which the object with the script is a part.

Because SL is so strongly script-oriented (and will probably become even more so as LSL improves), the above problem very strongly impacts on the good job that the client cache is trying to perform, and exactly the same would apply to regionalized caching clusters.

Regionalizing caches aside, algorithmic changes are needed in this area. Object dirtying with scripts needs to be reduced in its effect on cached object invalidation, and link set contamination needs to be stopped entirely except when other objects in the set are actually affected.

[Posted on weblog by: Morgaine Dinova | October 30, 2004 04:43 PM]

In a nutshell, geographic regionalization of object caching clusters could help everyone in principle, regardless of where they live and regardless of where an event is held, because caching servers would cache long-lived objects irrespective of home zone.

In contrast, geographically regionalized zone servers only help those currently at home in their own zone, or in other zones sited locally. This helps not at all when they go to events in other parts of the SL world, and it actually reduces performance for everyone else.

Furthermore, it introduces unfairness. Would you want to play a competitive game hosted in a Japanese zone server, in the knowledge that the locals have an inbuilt speed advantage over you?

The same applies to US-located servers right now of course, but regionalized caches can overcome the disparity to some extent, whereas regionalized zone servers cannot.