> Not sure what you mean by it not scaling - can you elaborate? Sure it > uses more ram than multiplexing, but even for a high traffic mail > server like apache.org's the mail-in-apache2 model works well > (apache.org uses Apache::Qpsmtpd for email). > > I'm curious as to how you've mixed things up though - if the details > aren't private IP I'd love to know more.
I'll cut in so that Stas can save his keyboarding wrist. Our application requires establishing lots of very long running SMTP connections -- in busy sites, thousands. Most SMTP applications handle all connections in a short period of time, meaning the average process load is manageable. Our application selectively slows down connections, causing the connection load to go up even though the CPU isn't doing any more work. Since it's not possible within reasonable memory constraints to have thousands of Apache mod_perl processes resident, our application needs to be designed using an approach that can allow multiple SMTP connections per Perl process. Instead of having one multiprocessing-oriented Apache mod_perl process per SMTP connection, we use a single event-driven process to handle all SMTP connections. To avoid blocking in this single process, we dispatch any CPU-intensive tasks to a pool of Apache mod_perl processes via a simple TCP protocol. We also dispatch out any tasks which are difficult to re-program using asynchronous IO calls -- including calls out to libraries written by third parties (such as spam scanning engines). We are considering open sourcing the asyncronous API we built on top of Event::Lib when we have time to refactor the application to separate it from the application's proprietary parts. TTUL Ken -- MailChannels: Assured Messaging (TM) | http://mailchannels.com -- Suite 203, 910 Richards St. Vancouver, BC, V6B 3C1, Canada Direct: +1-604-729-1741
