[ On Thursday, April 28, 2005 at 05:58:51 (+0200), RootChaos wrote: ]
> Subject: RE: [exim] Exim Performance / Server Performance
>
> Perhaps I should have added that the MySQL server is also on a totally
> separate server. We use a PHP frontend to administer the mail database which
> makes it easy for adding / removing users to the database as well as setting
> various other options like mail quotas etc.
That's really silly.
It's trivial to tune modern unix systems to handle upwards of 100,000
users or more in their normal system password files since all the decent
systems these days offer nice fast hashed database access to account
info. In fact that was true almost a decade ago already (on hardware of
the day) with all *BSDs and Solaris-2.5, so today I wouldn't be very
surprised if that with the right I/O subsystem the machine you mentioned
wouldn't be able to handle twice, or even ten times, as many mailboxes.
E-mail handling performance is all about the I/O _throughput_.
All mailers and such, old and new, will, by default, use normal system
accounts. It doesn't get any simpler.
Finally it's also trivial to write a little script that can be called
from cron every half hour or so to pull a list of valid accounts from
any SQL based database server and transform it into the standard system
password file. (though it's easier to write it in python or ruby, even
if much more expensive to run, than it is to write it in plain sh + awk :-)
Add these things together and you should realize that it's extremely
silly to be doing full SQL queries to any back-end SQL database for each
and every e-mail action. Just do one bulk query every half, or quarter,
hour or so and be done with all the unnecessary overhead and extreme
complexity of direct database lookups. Use the right tool for the job,
i.e. the right kind of database, in the right place.
As an added bonus you regain full OS-level (i.e. true) per-user security
(i.e. full AAA for anything and everything else you might want your
users to be able to do, such as having their own personal web pages or
whatever).
And this "pull" scheme is still quite scalable to multiple servers too,
if you should be so unlucky as to have several millions of users to deal
with, that is....
(though with Cyrus IMAP, even using "quota_db: skiplist", I found I had
to query the quota setting first to see if it needed changing before
resetting it to a new value as otherwise a half-hour refresh of 25,000
accounts from the DB was hammering much too hard on the system, though
that could have been fixed by locking the quota_db completely and then
rewriting it all at once, if only I had a direct skiplist object module
hand for python to do that with....)
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
