On Tue, 10 Apr 2001, Frank Beale wrote:
> I have the opportunity to setup a pop mail system for a client that
> will have 35,000 accounts but only the possibility of 160
> simultaneous connections. Does anyone have any real world
> experience if qpopper can handle this much load and what would be
> the most efficient way to authenticate this many accounts. We
> really want as much speed as possible.
In a previous life, I worked for an IT group that administered a pop
machine that served about 55,000 users. Not all of those users
actually used POP (in fact, we were trying to phase it out in favor of
IMAP), but we could have several hundred people using the pop machine
at once.
My guess is that with decently fast hardware, you'll be able to handle
the load, but there are several gotchas to watch out for:
1. Password file lookups (getpwnam and friends) must be hashed, a
la nscd or some other mechanism. If getpwnam() enumerates (on
average) 17,500 password file entries on each invocation, you
are toast.
2. You must hash the spool directory somehow. Having 30,000+
directory entries will kill the performance of
directory-related operations under ufs or e2fs.
3. You must find a way to prevent rewrites of large pop spool
files. It's not the size of the pop spool file that'll take
you down by itself; it's the rewriting of multi-megabyte files
that'll do it. You want to prevent your users from leaving
mail on the server at all costs; failing that, find a way to
efficiently apply a quota to the mail spool files. *Don't*
assume you can rely on standard ufs/e2fs quota subsystems
unless you test them; at least for older version of Solaris,
the quota subsystem simply couldn't handle tens of thousands
of users without becoming a huge bottleneck.
For caveat #3, I would recommend at least investigating using the
Cyrus POP/IMAP server instead of qpopper:
http://asg.web.cmu.edu/cyrus/
The Cyrus server stores each mail message as a separate file, which
eliminates the need for rewriting completely. The Cyrus server also
has built-in quota mechanisms that do not rely on the underlying
filesystem.
The main disadvantage of the Cyrus server is that it eats inodes, and
uses more actual disk space to store the same amount of data (the
result of rounding [n] files up to the block/fragment size instead of
just one file). It's also more complex to set up and administer than
qpopper. But for a large site, I think it may be a win over qpopper.
(Note that although I am affiliated with CMU, I am not affiliated with
the Cyrus Project; the above opinions are my own.)
Regards,
--
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
