Subject: Mem/disk requirements for large IMAP server?

From: "Mark Thacker...CC1 LAN Manager" <[email-masked]>
Date: 22 Dec 1993 11:06:34 CST6CDT

Hello all,

Has anyone done any estimating (or actual implementation) of an IMAP server 
for several thousand accounts?  We want to run 30K students on a single IMAP 
server and need estimates of disk size (yeah, I know, it depends on how many 
messages), memory requirements and CPU power with reference to a Sun based 
system if possible.

Our biggest concern is if someone sends a copy of a message to everyone on 
the system, are we going to get 30K individual messages?  I think the answer 
is yes.  So, we need estimates of disk size needed in a "live" system.

Any estimates or hard numbers for any existing system would be very useful.  
Thanks in advance for all of the help.

Mark

======================================================================
Mark Thacker                                     Bitnet : MARK@UNTVAX
Campus Wide Information System Coordinator      THENET : NTVAXA::MARK
Computing Center                           Internet : [email-masked]
University of North Texas, Denton, Texas  76203        (817) 565-2568
======================================================================

---

From: Mark Crispin <[email-masked]>
Date: Wed, 22 Dec 1993 22:36:53 -0800 (PST)

Hello -

     It is rather difficult to answer your question precisely, because it
depends upon so many different variables.

     One of our IMAP servers is a single DECSYSTEM-5000/200 with 120MB of RAM.
It typically runs loads of 160 simultaneous imapds without a hiccup.  The
users of this server typically use the standard UNIX format of mail which
reads the entire mailbox file into memory.  Alternative formats of mail such
as tenex or MTX are much less memory-hungry than the standard format but may
beat on the filesystem a bit more if you do a lot of free-text searches.

     It is difficult to judge how much disk space 30,000 users would need.  If
you assume that an ``average'' user uses 1MB (some people would call this
generous, others miserly), then we're talking about 30GB of disk.  I think
that this is quite a bit larger than will actually be needed (although note
we're talking about $1/user pricing for modern disks).

     In general, I feel that a set of smaller, less expensive servers is
better than an attempt to have a single monolithic server to handle an entire
university's mail load.  This is the case whether or not IMAP is in the
picture.  In general, you can put quite a few more IMAP servers on a machine
than you can put timesharing users running a mail reader and maintain a
satisfactory level of service.

     Another benefit of smaller servers is that it is much easier to scale
such systems, e.g. adding disk capacity or splitting an overloaded server in
two.  Means abound for allocating users to servers; departmental or other
administrative boundaries, first letter of name,...  A protocol called IMSP
under development at Carnegie-Mellon University (contact [email-masked] for more
information) will permit the automation of this procedure.

     I think that if you start out with a small set of servers (2-5), each
with a few GB of disk space on them and split the user community more or less
evenly between them, then you'll be able to monitor how usage consumption
rises.  You should be prepared to throw more disks (and, to a lesser extent,
more servers) at it with relatively short advance notice.

     A truism in the computing industry is that usage grows to meet and
eventually exceed available resources no matter how large the resources are.

     As for your question:
> the system, are we going to get 30K individual messages?
 This is a function of the format you choose to use for mail.  The mailbox
drivers provided with c-client (the underlying engine behind Pine, the IMAP
server, etc.) use individual copies of messages.  However, this does not
prevent one from writing a driver (such as was used in the European COM
system) which has one instance of a message on the disk for any number of
recipients.

     However, I don't think that ``a message to 30,000 users'' is going to
happen.  Many mail composition programs would collapse ungracefully if someone
attempts to send a message to 30,000 recipients.  This is a Good Thing; given
that a typical e-mail address is 25 or so characters, the header of such a
message would be nearly 750K bytes!  If the mail composition program does not
prevent it, generally it will not be long before the system administrator
observes the developing catastrophe and stop it (and then has a ``nice little
talk'' with the offender...).

     In general, such ``broadcast'' messages use netnews or some similar
bulletin board mechanism, which is designed for this purpose.

Regards,

-- Mark --

---

From: "John Ladwig" <[email-masked]>
Date: Thu, 23 Dec 93 07:21:39 CST

>>>>> On Wed, 22 Dec 1993 22:36:53 -0800 (PST), Mark Crispin <[email-masked]> said:

    Mark> [...] It is difficult to judge how much disk space 30,000
    Mark> users would need.  

I don't have the figures, but [email-masked] would be able to
tell you how much space approximately 65000 *accounts* (last figure I
heard was 15-20% actively in-use accounts).  The University of
Minnesota in Fall Qtr 92 instituted campus-wide email, to the tune of
~110,000 users.  Eeek!  Can you say "geez, uid_t is only an unsigned
short, and it *matters* to us?"

    Mark> In general, I feel that a set of smaller, less expensive
    Mark> servers is better than an attempt to have a single
    Mark> monolithic server to handle an entire university's mail
    Mark> load.  

Last I heard, "gold.tc.umn.edu" was three Sparcstation 10s (don't know
the model) sitting behind a DNS shuffle record (local nameserver
hack), with their user directories AFS mounted from two RS/6000s,
chosen for their journalling filesystem.  I believe there's another
RS/6000 or Sparcstation in the pool somewhere as a sendmail delivery
agent.  Our other central mail "machine", maroon.tc.umn.edu is some
sort of large multi-processor CDC/EPX machine, and it takes 3/4 hour
to fsck the 4GB home partition if it has to reboot...  Maroon is
scheduled to be carved up into a model similar to gold early next
year.

    Mark> This is the case whether or not IMAP is in the picture.  In
    Mark> general, you can put quite a few more IMAP servers on a
    Mark> machine than you can put timesharing users running a mail
    Mark> reader and maintain a satisfactory level of service.

gold.tc.umn.edu is nominally a "student" "machine", and
maroon.tc.umn.edu is a "staff" machine (the actual boundaries break
down some, now that we have more than 65000 student accounts).  maroon
has a larger percentage of active users, and is a single (albeit
higher-capacity) machine and the machines comprising gold.  

The usage pattern is *very* different between the two machines.  Staff
and faculty, since they usually have a reliable, predictable place to
read mail from, generally use POPmail (our local microcomputer folk
don't really do IMAP, except as a POP emulator :-( ).  Students, since
they are bouncing in from lots of different public labs, generally use
an interactive session, with a menuing shell, and a copy of pine.
Puts a tremendous load on the servers, by comparison.

Get your clients to use a real IMAP client as early as possible; based
on what I've seen (from a slight distance) here at UMN, it'll cut down
your hardware costs dramatically.

---

From: "Carolynn Seeley ( Spring )" <[email-masked]>
Date: Thu, 23 Dec 1993 10:16:25 -0500 (EST)

I have completed the upgrades to PINE 3.88 from 3.07 on a SUN; to 3.88 
from 3.05 on a Solaris; and to 3.89 from 3.07 on an SGI.  

A few of my people have been reporting a problem with PINE 3.89 on the 
SGI. When they start their PINE session the Main menu comes up with the 
message 'Opening INBOX' and then [after a beep] the message 'Unparseable 
date' appears in the command line. PINE seems to open everything and run 
fine and the error message disappears after a few screen changes. 

Any ideas? Has anyone else run across this? 

Thanks for your help, and Happy Holidays to you all.

-------------------------------------------------------------------------------
Carolynn Seeley (Spring)             email:  [email-masked]
Consultant, Desktop Support                  [email-masked]
Computing and Information Services     
McMaster University, JHE-122
(905) 525-9140              x27090     
------------------------------------------------------------------------------