[136] in Zephyr Mailing List
New server running at MIT with optimizations
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Tue Aug 16 22:01:09 1994
From: ghudson@MIT.EDU
Date: Tue, 16 Aug 94 21:57:50 -0400
To: zephyr@MIT.EDU
We've installed a new server binary on one of our servers here at MIT,
with several significant optimizations. Even with it only installed
on one of the three server machines (and linked against the old,
slower DES library), we've had two users so far comment to the effect
of, "Zephyr is running unusually fast today; has something changed"?
The optimizations made were (according to my memory):
* Previously, the servers would block SIGFPE while making updates to
the subscriptions database, to prevent database dumps from being done
during an update. Richard Basch scrapped this in favor of a global
flag turned on by SIGFPE and checked during the main loop.
* Previously, subscription lookups were handled very poorly; in
particular, each personal message resulted in a walk over half of the
subscriptions in the database. I changed this to hash destinations by
full triplet and avoid doing unnecessary memory allocation for
subscription lookup. This should be a couple of orders of magnitude
faster.
* Previously, timers for unacked packets were handled with a simple
ordered linked list. I replaced this with a heap implementation,
which is a lot harier (in addition to verifying the code logically, I
tested it rigorously by comparings its results against the old
implementation with random sequences of timer operations), but
considerably faster for large numbers of timers. I don't know how
much this affects the server speed in practice, but when none of the
clients are acking packets (under simulation), this cuts down the time
spent in insert_timer() from ~35% to less than 0.1%.
* Inserting and removing subscriptions is a little bit faster; it
wasn't very slow to start with, though.
Currently, the biggest time hogs for the server appear to be
ZCheckAuthentication(), sendto(), and recvfrom(). We can't do much
about the latter two, of course, but we're working on some (minor)
protocol changes that should allow us to cut the time spent in
ZCheckAuthentication() down to a few percent.
For those of you outside MIT, we may be able to put together a release
soon, but I haven't checked on this.
Finally, for those of you interested enough in Zephyr to read this
far: I'm working on a design document for a replacement for Zephyr,
designed to solve some of Zephyr's scaling, performance, and
complexity problems. I'm soliciting ideas and opinions about the
design of a messaging service. (Yeah, I know I'm not the first.) If
there's enough interest, I could create (or revive) a mailing list and
discuss meeting for discussing this.
