On 7/25/06, Leonardo Helman <[EMAIL PROTECTED]> wrote:
> When you are talking about concurrent connections are you then > refering to established connections from netstat ?, or actual > connections doing qpsmtpd work ?. When qpsmtpd can catch up to the incomming traffic the netstat/forked are roughly the same. When it can't process all the connections, they start queueing in the backlog (SOMAXCONN) and the client has to wait for a minute to receive the 220.
Yep - what I meant was if you try to prefork processes enough to deal with such a load you will need a really big server. All my tests with prefork seams to indicate that 120 connections (at least with our scanning needs on a dual 3ghz xeon) is maximum, above 120 our load sky rockets, scanning times get high and not much extra email is handled.
At first sight the qpsmtp-prefork have the QUIT issue (there is a mail in the list and a commit talking about this, but the patch is not really commited)
What quit issue are you referring to here ?. I submitted the original qpsmtpd-preforking daemon and will be very interested in ironing out any remaining problems with it. The version in the 0.3x branch works fine for us (remember to use the two subclassing modules). -- Lars Roland
