[MUD-Dev] Server stability (was: Player statistics)

[Koster]

> -----Original Message-----
> From: mud-dev-admin at kanga.nu 
> [mailto:mud-dev-admin at kanga.nu]On Behalf Of
> Bruce
> Sent: Tuesday, January 16, 2001 7:41 PM
> To: mud-dev at kanga.nu
> Subject: Re: [MUD-Dev] Server stability (was: Player statistics)
 
> What happens in some of the text games in this way (while there are
> players online) makes me feel ill.  I'm a strong believer in
> integrated content management (and source control) systems, but
> those do not in anyway limit the ability to do updates that don't
> involve downtime.

Technically, the system in UO doesn't require downtime. It's just
considered good practice. Not sure about EQ or AC.

There is one exception, which is a key difference from text muds, and
that's client-side patches. You generally do not want the client code
and data to get out of sync with the server code and data, even for
brief periods of time (or else strange effects may result) so if you
are doing a client-side patch, you generally force downtime.

> Also, if you limit yourself to large patches which require downtime,
> you're limiting the ability to do smaller, more piecemeal changes
> because you don't want downtime that frequently.

Well, I guess I shouldn't mention the time that the UO servers had
some sort of critical bug we couldn't replicate and couldn't find but
which caused lockups, so we just ran an actual live server under the
debugger, caught the error, and fixed the screwed up data in memory on
the fly while we prepped the fix. I remember standing over Rick's
shoulder as he did it, both of us knowing that 2500 people were
locking up while he worked in gdb. :) It does happen, it's just not
desirable. :)

> I do recognize that there are some updates that will very likely
> require downtime and that the engineering cost to avoid those would
> outweight the benefits.  But with some of the trends that are
> currently visible in the industry, I wouldn't be surprised to see
> smaller updates become more common (and therefore a necessity at the
> technology level).

Given the QA process involved in posting changes to live servers, even
small updates have significant overhead--too small a change is more of
a pain to test than getting several small ones into one update. So an
"optimum size" seems to be what has evolved.

-Raph
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev