I actually run forkserver, now prefork, under daemon ( http://libslack.org/daemon/) which handles all of the logging to syslog, or file, and restarting the process if it fails. Works great on our boxes and is much easier to run than tcpserver or svscan. I use: /usr/bin/daemon --chdir=/home/smtpd/qpsmtpd/ -N --name=qpsmtpd-daemon \ --pidfiles=/var/run --respawn --stdout=mail.warning --stderr=mail.warning \ -- ./qpsmtpd-prefork
To start prefork for instance. Speaking of which, I've now moved all of our servers to the 0.40 prefork and haven't had a problem yet once I got my plugins tuned right. Looking at moving to async but I'm still confused as to what all is required, or I guess I should say recommended, in rewriting plugins to be async. I'm a learn-by-example type of guy so any examples for say the spamassassin plugin or maybe clamdscan would help me out a lot. Once I've got the how to do it down I'd be more than willing to convert a lot of them over and post them back on the list or on my site. On 8/16/07 3:09 PM, "Peter Eisch" <[EMAIL PROTECTED]> wrote: > > On 8/16/07 1:45 PM, "Charlie Brady" <[EMAIL PROTECTED]> > wrote: > >> >> On Wed, 15 Aug 2007, Joe Schaefer wrote: >> >>> [EMAIL PROTECTED] (Charlie Brady) writes: >>> >>>> AFAICT, nobody has ever said what constitutes 'faster', or what >>>> performance testing has been done forkserver v Apache::Qpsmtpd. >>> >>> When SMTP transactions are measured in seconds, "faster" really >>> doesn't matter unless you're talking about how quickly you can >>> fail a bad connection. The big win with Apache::Qpsmtpd over >>> forkserver at Apache, IIRC, was in measuring the ratio of forks >>> to connections. With forkserver, the ratio is 1-1, whereas >>> with Apache::Qpsmptd it's configurable within httpd, and for >>> apache is on the order of 1 fork per 5000 connections. >> >> Is there evidence that the forks (and subsequent COW) have a significant >> effect on latency - i.e. how quickly you can fail a bad connection? >> > > <pseudo-religion> > > I don't have tcpserver available on my OS natively and I have to go through > some hoops to get it on there that include some various acknowledgements to > the author. Forkserver worked fine for me until it would just fade away. > (That was under 0.28, to be fair.) Then with forkserver I had to jump > through some hoops to set up ulimit properly and if a peon didn't restart it > properly, things would just fall apart. > > I have apache running on these systems already for other reasons (mostly > admin & monitoring) so moving to Apache::Qpsmtpd was really a natural fit. > I like that I can set up each of the 'listeners' in separate conf files > specifying the IP and ports to my pleasure. > > As to the overall efficiency and speed, I'd really figure that -async can > lay a beat-down on anything that doesn't select() socket arrays. > > With all that said, I rely on syslog for any events that get written to > disk, so I may not be the right person to ask about this stuff. (Though I'm > close to logging solely to sql. <grin>) > > </pseudo-religion> > > peter > > -- Ed McLain
