Matt Burgoon a écrit :
> 
> I'm running into some performance issues with the sheer volume of email
> I'm dealing with that is destined to a perl script for final email
> delivery. The start up cost of this particular perl script is not
> insubstantial, and is slowly bringing this poor box to its knees. I've
> done as much optimization as I can, and the only logical next step is to
> turn it into a daemon, so I no longer have to worry about the initial
> start up cost of this script.
> 
> I've played around with creating a new service, when defined as a pipe,
> which works, but it still forks off a single process per mail that is to
> be delivered. I've tried to redo it by using spawn, but that's actually
> not working, and I don't think it will as I believe it will only hand
> over the headers as it would for my SPF+greylisting script, not the full
> body which I need.
> 
> I fully expect to have to implement that can actually speak LMTP or
> something else postfix speaks, so I have no illusions that this is going
> to be super easy.
> 
> Does anyone know of anything/anyone that currently does this? Any
> suggestions on how to configure postfix to talk to something else for
> delivery (preferably spawned off by postfix itself, but not a
> necessity)? I wasn't expect to be unable to find anything, as I would
> have guessed that this is probably #1 on the high performance list when
> doing something fancy, such as delivering to dovecot/cyrus/etc as I
> imagine those aren't overly cheap either. Unfortunately, my search has
> turned up not much, just the same old stuff on how to use a milter and
> the SPF/greylisting how-to's.
> 
> If worse comes to worse, I can run this script as a daemon that accepts
> unix socket connections, then have the local delivery agent replacement
> just make a connection, spew the email over the connection and exit, but
> I was hoping to do something a bit more robust, as that solution means
> I'm bound to only one CPU at that point (part of the start up cost is DB
> connections and stuff, which can't be safely shared by perl processes
> that get forked off.)
> 
> 
> 

start by telling us why you can can't use maildrop.

Reply via email to