Vas wrote:
| background:
| An existing mud is toying with the idea of re-writing the mudlib to
| take advantage of the advances to the MudOS driver during the past 6
| years. One of these is the addition of the SQL package.
|
| questions:
| is this a good idea for an lpc mud (being that it is a non-threaded
| application)? is this more of a convenience feature vice a performance
| update? is anyone willing to share their experience with using SQL
| with an lpc mud?
|
| I thank you in advance,
| Raul
The biggest problem with trying to use SQL in any lpmud is that the lpc
language has to remove resource limiting aspects for the duration of a
query (ticks, milliseconds, whatever your particular lpc driver uses to
determine runaway conditions and stomp them), which may result in
horrendous lag in difficult to predict ways.
I use PostgresSQL myself, and one good example is a non-linear slowdown
of a table that has lots of inserts/updates. Let's say you decided to
put all the mobs in a table, and update the row each time a mob was
killed, or each time the mob killed something else -- a simple
kills/deaths column. With a smallish table of 5000 mobs, this should be
pretty quick, but you probably want an index on pathname anyways, since
adding new mobs won't happen all that often. Postgres needs you to
vacuum/analyze tables every so often to keep the statistics up-to-date,
else the planner starts miscouting rows and making poor choices about
when to use an index. The result would be a mob lookup suddenly taking
250ms instead of 10ms... adds up over time quite a bit.
The other thing is that latency of a database is usually much worse than
latency of a disk filesystem... unless you have most of the data cached
in RAM. If you have a hefty enough machine to manage this, you needn't
worry too much unless you do very hefty joins.
The OTHER way you could do this is to add the code to the lpc driver as
a threaded callback. Basically, spawn a seperate thread/process to
handle the actual database I/O, and each time around the processing
loop, see if your query is finished. If so, gather the data and pass it
into lpc space, then insert a callback to an lpc handler routine. Much
more complicated, but that would avoid the lag issue and pass it along
to the local thing needing the data (IE: instead of the whole mud
lagging, the thing trying to load a magic sword for Olaf would take a
second or two, so Olaf would have to wait, but the rest of the game
would go on).
It would be cool to see something like that happen and work well... but
it's a bit beyond my scope at the moment!