Quote:


I think he over simplified the back end architecture.
I'm sure there's more than one physical server running each world.

Things as I see it you have a cabinet of blade systems ( say 50 servers... ) Each server can handle a given number of instances simultaneously. ( say 100 )
In these 50 servers you have 2 or 3 servers dedicated to database transactions ( they are not part of the instance cluster ), and 2 or 3 more dedicated to coordination between all the servers ( they are part of the instance clusters but don't run actual instances, they are the ones that tell the other servers to spawn instances when necessary... or that move an instance from one server to another. )
Now for reliability purpose, every instance spawned is duplicated on two different blade. That way when the instance crash on one of the blade, the other blade can take the action on the fly while the crashed instance is reset on the relevant blade.

I suspect that some of the lag spikes we encountered ( typical case : when somebody Disconnect ) were caused by the instance crashing and us being 'transfered' on the second blade that ran the instance we were in.
As the blade used in secondary role in the above example is also handling other instances in the primary role when we get transfered ot it because of a crash we get lag, because we are the low priority job.

Anyway, I'm not sure I'm clear...

Flav wrote on Nov 23^rd, 2011 at 3:52am:



no that would describe it fairly well I think.  Whatever the mechanics, it appears that based on his comment that the switching to the back up instance is overloading the server, in other words the failover is enough to keep us from crashing out altogether but the box is not strong enough to stay performant with the extra load.
The real question is whether the whole server is crashing thus dumping all instances at once or are individual instances being dumped out.

Quote:


I suspect it's just the instance ( as I suspect that a given instance is a thread spawned on a given server either as a 'general open' [ Market, Harbor, Houses ] instance or a quest instance. ) that crash. And the Lag spike is generated by the handover to the other server, not by the load... The lag generated by the load is always there and should be constant ( as long as your instance don't crash ).

Balthazar wrote on Nov 23^rd, 2011 at 10:57am:


I didn't want to make things too complex...
Several virtual servers over several [ different several ] physical blades all in a cluster. I don't think they went the mega server way with several virtual beasts. Too much capital invested in that mega server. It's cheaper to buy blade chassis and put the number of blades needed... you can then add/remove them dynamically when the load change. Thus maximizing your revenue and minimizing your costs.

The other point being that the former European Servers were hosted at an ATT Datacenter in Netherland... I don't expect CM to go there from UK every week to manage the server hardware. So something that can be soft configured sounds more appropriate. You rent the hardware, when you need to add more you ask for more to be added, when you need less you release some of the hardware to the lender.