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.)



Reply via email to