Date: Fri, 02 Jun 2000 15:34:14 +0100 From: Simon Wistow <simon@profero.com> To: acmemail <acmemail@astray.com> Subject: Re: [acmemail]High Scalability Email > I am looking for an email system that would be perform well and be infinitely > scalable, up to Millions of users. > > Can anyone give me an idea of how scalable ACMEmail is and what kind of > performance could be expected under load? I don't know about millions but there's no reason why Acmemail shouldn't be highly scalable. I've set Acmemail up for an ISP which was intended to easily scale to 25,000+ users and that was on one Sparc box running Solaris (which has some *horrific* memory leaks). We used ... o Apache <URI:http://www.apache.org> This is really down to you. It's be interesting to see what benchmarks you get when running Acmemail under something else like Roxen <URI:http://www.roxen.com/> or Zeus <URI:http://www.zeus.com/>. o mod_perl <URI:>http://perl.apache.org/> This makes the httpd process very large but it means that you don't have to fire up the perl interpreter everytime you get a hit. And once it's up it doesn't tend to get much bugger. Alternatively look at SpeedyCGI <URI:http://daemoninc.com/SpeedyCGI/>. o Mysql <URI:http://web.mysql.com/> As the session store although you could conceivably use Oracle <URI:http://www.oracle.com/database/>, Postgres <URI:http://www.postgresql.org/>, Sybase <URI:http://www.sybase.com/products/databaseservers/> or anything else. We currently in the process of preparing to move to Apache::Session <URI:http://theoryx5.uwinnipeg.ca/CPAN/data/Apache-Session/Session.html> so it would be interesting to see how that affects scalability. The fastest and most light weight session store we've seen is using IPC::Cache <URI:http://theoryx5.uwinnipeg.ca/CPAN/data/IPC-Cache/Cache.html>. o Cyrus IMAPd <URI:http://asg.web.cmu.edu/cyrus/> Cyrus is optimised for lost of users with no shell accounts. Which sounds like what you want. The University of Washington server <URI:http://www.washington.edu/imap/> apparently leaks memory quite hard and has quite a few security holes. Alternativley you could use POP3 but I think IMAP is going to end up being more scalable. For POP3 daemons you could do worse than the GNU pop3d <URI:http://www.nodomainname.net/software/mailutils/> or popa3d <URI:http://www.openwall.com/popa3d/> which is very small and very secure. o Exim <URI:http://www.exim.org/> Exim was just a bit more lightweight than Sendmail <URI:http://www.sendmail.org/>. Qmail <URI:http://www.qmail.org/>is an option as well. The latest (CVS) version of Acmemail should be a lot more scalable than the last one because MIME stuff is decoded on the fly and on demand rather than written to disk everytime a message is viewed. With the correct load balancing set up, say a web farm for the Acmemails, a database server (cluster?) for the sessions and an IMAP cluster there's no reason why Acmemail shouldn't scale. Let us know how you got on. Simon = References = Building a Large Email Service - http://slashdot.org/askslashdot/99/07/29/2152242.shtml POP3 and Large Mail Boxes - http://slashdot.org/askslashdot/98/10/02/206230.shtml mod_perl performance tuning guide by Vivek Khera. - http://perl.apache.org/tuning/ The Imap Connection - http://www.imap.org - http://www.imap.org/products/longlist.htm _______________________________________________ acmemail mailing list acmemail@astray.com http://www.astray.com/mailman/listinfo/acmemail