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
