On Mon, 5 Jul 2004, Eric Ziegast wrote: > With webmail, the session state is not saved nor cached, so with each > new request, the mailbox can be rescanned. A relatively modest webmail > application might only rescan all headers and show subject lines. A > complex application might scan all content in a folder to present > content more fully. Without anything to throttle back the webmail > server, it's possible that the webmail server softwar can pound the mail > spool server to death.
There's two things I'm testing. The first is Turck-MMCache, which is a caching lib for php, similar to the commercial Zend stuff. It's free though. It saves all the overhead of compiling your webmail stuff on every hit (it caches pre-compiled code). This of course assumes you're using a php-based webmail app. The other thing I'm looking at is an IMAP cache, which could probably help with the problems you're seeing as well. The squirrelmail list has some good info on this. > I used to run a Qmail-based infrastructure for 4000 clients on a > single slow machine without much memory. The machine that this mail is going through is an AMD K6-2-450. It has maybe 20 or 30 mailboxes, tops. For years it has been more than adequate for this small task, but with a few catchall domains and no "chkuser" patch (I don't trust it as it rejects mail if mysql is not zippy enough) it can really get bogged down during spam runs. I'm sick of building boxes to accomodate all the spam; I need to build for the 85% of mail that just gets thrown away by SpamAssassin. That's my spam rant. :) > Instead of the centralized NFS mail spool (where the central spool > becomes the bottleneck), you might consider splitting the user base > across several machines. Each machine would have its own RAID1 > mail spool. Each machine would be responsible for its own > Inbound SMTP and POP/IMAP/Webmail and use the local disk for the > spool. Use lots of RAM for "buffer cache" to make sure your disk > is hit less frequently. You might be able to centralize outbound > SMTP. Once a machine "fills up", you add another machine. This is > one way to scale. That's been my plan, but my problem is that most of my users are all under one domain, so I'm not really sure how I can divvy up the users without yet another box doing mx in front and splitting the mail up... > The big boys in teh mailbox size wars (google, yahoo, hotmail) can't > afford centralized storage for their mailboxes. Look for each to > roll out racks of distribtuted storage where each "storage server" is > a 1/2 U box with a couple large ATA disks in it. We might learn from > this method of scaling. Hopefully one of them will do a nice Usenix presentation like Earthlink did back in the day... Thanks, Charles > > -- > Eric Ziegast >
