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.