> 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

Reply via email to