[crossfire] Proposal for player logfile / plugins

[Andreas Kirschbaum]

Nicolas Weeger wrote:
> It seems the slow issues Metalforge has been experiencing are related
> to Python, and possibly due to the size of the logfile (log containing
> birth date, kick info, muzzle, and so on).

I agree that the lags for players logging in on mf are probably related
to Python. (Disabling Python did "solve" them.) But I have concerns that
the real cause of these lags is indeed the size of the logfile
(Player_log):

A while ago Leaf told me that the Player_log file on mf was about 226k.
At that time the server did lag for about 5s for every player logging
in. I created a Player_log file with 4901k size (50000 players) on my
own server. This did lag my server for about 5-7s (on a *much slower*
computer).

Since the Python parsing function should scale linear with file size,
and if I assume that mf is (much) faster than my computer, the 226k file
should result in a lag of (much) less than 0.3s (=6s*226k/4901k) on mf.

That said, I'm still not convinced that the size of this file is the
real cause for these lags.


> My proposal is to split this file, putting player's information directly
> in the player's directory.
[...]
> Drawback (for logfile at least), no more consolidated file with all the
> info - but shouldn't be too hard to do a script to merge all info for
> statistical purposes.

Maybe it could be interesting for DMs to know which players did log in
from an ip address (or ip address range)? With the split info approach
this feature probably is not possible.

And I don't think using such a script is a good idea: it creates another
external dependency. (And the Python scripts accessing this collected
information probably will not detect old (i.e. not updated) information
in case that external collect script fails to run.)


> What do you think of that?

Removing code that does not scale well is probably a good thing to do.
An alternative approach to consider: use a file format that does scale
much better.

Note that a previous commit apparently did the reverse thing: replace an
efficient file format by an (accessible but) inefficient file format:

| # cvs log python/CFLog.py
| [...]
| Working file: CFLog.py
| [...]
| revision 1.3
| date: 2004/09/01 02:03:25;  author: temitchell;  state: Exp;  lines: +48 -28
| [...]
| - replace crossfirelog shelf with plain text datafile (less efficient
| but more accessable)
| [...]