Re: Performance / Tuning questions
On 2007-08-16 18:45:08 -0500, Peter A Eisch wrote: On Thu, 16 Aug 2007, Charlie Brady wrote: On Thu, 16 Aug 2007, Peter Eisch wrote: As I noted, forkserver was hit or miss without some safeguard to catch when it tanked. And it did. Early versions of forkserver died if a child died at an inopportune moment. That was fixed quite a long time ago and I think it was only a problem with perl 5.6 (save signals in 5.8 should have taken care of this). Other than that I don't remember any case where the parent process of forkserver died. I have apache running on these systems already for other reasons ... Not everyone does. But your reasons for preferring one start script to another are beside the point. I'm merely trying to discover the details and the basis of assertions about performance. The assertion about performance is that can get Plugins already loaded 150 times or so per child (just looking at one child in the live logs now). If that is supposed to be an argument why apache must be faster than forkserver, I don't follow it. I don't get this message at all with forkserver (and since its at LOGWARN level, I should see it if it happens). I dimly recall that with some old version I did get it reliably once per child, because load_plugins was called a second time just after the fork - I don't remember when this was fixed. 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. That's speculation, not benchmarking. No, kind sir. Systems (W. Richard Stevens era) and kernel scheduler programmers understand this. There is a difference between potential performance and actual performance. Just because a select-based state-machine is potentially faster, doesn't mean it is measurably faster in the real world. There are too many other variables involved. So I agree with Charlie here. Arguing that something must be faster because it uses select is just speculation. If you want a real comparison, you need to benchmark it. Of course with benchmarks, you have to problem that you need a realistic workload, and with qpsmtpd you probably won't find two installations which use the same plugins, so results probably cannot be generalized. Metrics I think are relevant: Maybe you have some specific metrics you'd like for me to gather? * Processed connections per time unit. * Accepted messages per time unit. * Latency for accepted messages. * System load (for a given workload) * Memory usage (for a given workload) A change in these metrics when switching from one method to another on the same machine is probably a good indicator for a given set of plugins and a given workload. I don't think any set of metrics is comparable between different systems and different workloads. A synthetic workload might be useful, though. hp -- _ | Peter J. Holzer| I know I'd be respectful of a pirate |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | [EMAIL PROTECTED] | __/ | http://www.hjp.at/ |-- Sam in Freefall signature.asc Description: Digital signature
Re: Performance / Tuning questions
On 2007-08-15 20:27:24 -0400, Matt Sergeant wrote: On 15-Aug-07, at 7:08 PM, Ed McLain wrote: IS there any documentation anywhere on how and what needs to be changed? I've looked on the wiki and don't see anything on there about it. As an aside, I'll dig through the dnsbl plugin for async and see what I can come up with. Any information would be very helpful though. There isn't much documentation on it unfortunately. The big problem tends to be in the queue plugins as they do I/O - so for example in the postfix-queue plugin it opens a UNIX domain socket to the postfix queue daemon and squirts the message down that socket. All the time it is doing that, qpsmtpd-async could be processing other connections, but because it's not written in an async manner it can't. Good catch. I've been thinking of switching to -async (we have only ~50k connections per day on average, but it's very uneven, so the configured limit of 50 concurrent connections gets reached every now and then and I don't think I want to raise that any further), so that would be one of the plugins I'd have to rewrite (and one which I didn't think of, although in our case it probably isn't a bottleneck). hp -- _ | Peter J. Holzer| I know I'd be respectful of a pirate |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | [EMAIL PROTECTED] | __/ | http://www.hjp.at/ |-- Sam in Freefall signature.asc Description: Digital signature
Re: Performance / Tuning questions
On 2007-08-15 23:45:14 +0200, Stefan Priebe wrote: But would be more luckier, if yome of the devolopers seem to care. Cause qpsmtpd is a real great program i think... and it should be stable in a new release and not that buggy as it is... i think this is really sad / bad or whatever. I just added a link to the issue tracker (http://code.google.com/p/smtpd/issues/list) to the wiki. It might be a good idea to add all open issues there even if they have been discussed on the mailing list, just so they aren't forgotten. hp -- _ | Peter J. Holzer| I know I'd be respectful of a pirate |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | [EMAIL PROTECTED] | __/ | http://www.hjp.at/ |-- Sam in Freefall signature.asc Description: Digital signature
Re: Performance / Tuning questions
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?
Re: Performance / Tuning questions
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
Re: Performance / Tuning questions
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
Re: Performance / Tuning questions
On Thu, 16 Aug 2007, Peter Eisch wrote: ... and I have to go through some hoops to get it on there that include some various acknowledgements to the author. That's BS. Anyone is free to download tcpserver without any acknowledgements. If you don't like the ucspi-tcp license you can use ipsvd. But this is by the by, since forkserver doesn't use tcpserver. I think you mean to refer to supervise. If you don't like supervise's license, use runit. If you don't like supervise/runit, start forkserver from inittab. Then with forkserver I had to jump through some hoops to set up ulimit properly ... If ulimit bothers you, don't use it. I have apache running on these systems already for other reasons ... Not everyone does. But your reasons for preferring one start script to another are beside the point. I'm merely trying to discover the details and the basis of assertions about performance. 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. That's speculation, not benchmarking.
Re: Performance / Tuning questions
On Thu, 16 Aug 2007, Charlie Brady wrote: On Thu, 16 Aug 2007, Peter Eisch wrote: ... and I have to go through some hoops to get it on there that include some various acknowledgements to the author. That's BS. Anyone is free to download tcpserver without any acknowledgements. If you don't like the ucspi-tcp license you can use ipsvd. But this is by the by, since forkserver doesn't use tcpserver. I think you mean to refer to supervise. If you don't like supervise's license, use runit. If you don't like supervise/runit, start forkserver from inittab. Check out http://pkgsrc.org/ and try and install tcpserver without jumping through hoops of license agreements. As I noted, forkserver was hit or miss without some safeguard to catch when it tanked. And it did. Then with forkserver I had to jump through some hoops to set up ulimit properly ... If ulimit bothers you, don't use it. ...and... I don't. I have apache running on these systems already for other reasons ... Not everyone does. But your reasons for preferring one start script to another are beside the point. I'm merely trying to discover the details and the basis of assertions about performance. The assertion about performance is that can get Plugins already loaded 150 times or so per child (just looking at one child in the live logs now). Maybe you have some specific metrics you'd like for me to gather? 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. That's speculation, not benchmarking. No, kind sir. Systems (W. Richard Stevens era) and kernel scheduler programmers understand this.
Re: Performance / Tuning questions
On Thu, 2007-08-16 at 18:45 -0500, Peter A Eisch wrote: That's BS. Anyone is free to download tcpserver without any acknowledgements. If you don't like the ucspi-tcp license you can use ipsvd. snip Check out http://pkgsrc.org/ and try and install tcpserver without jumping through hoops of license agreements. Why not just get it from the original author at cr.yp.to ? I don't see how the jokers at 'pkgsrc' can impose further restrictions on something they did not write. -- --gh
Re: Performance / Tuning questions
On 16-Aug-07, at 8:32 PM, Guy Hulbert wrote: On Thu, 2007-08-16 at 18:45 -0500, Peter A Eisch wrote: That's BS. Anyone is free to download tcpserver without any acknowledgements. If you don't like the ucspi-tcp license you can use ipsvd. snip Check out http://pkgsrc.org/ and try and install tcpserver without jumping through hoops of license agreements. Why not just get it from the original author at cr.yp.to ? I don't see how the jokers at 'pkgsrc' can impose further restrictions on something they did not write. Can we not let this list diverge into a massive licensing war please? End this thread. Matt.
Re: Performance / Tuning questions
Ed McLain wrote: Hello all, Got a quick question for all those out there running large setups using qpsmtpd. We currently have a setup which is load balanced across an several qpsmtpd servers running a custom linux distro that basically runs the entire setup in ram for maximum performance. Until lately the setup has been running absolutely wonderful but with all these spam bots running around I've started noticing some odd issues and I'm about to start pulling my hair out. I've tweaked and tweaked the sysctl vars for the network interfaces, disabled rdns, and also removed almost all of our plugins in an attempt to keep the machines running with the flood of incoming emails. My setup is as follows: Qpsmtpd v0.32 running with forkserver Maybe take Apache::Qpsmtpd for a spin. Anecdotal evidence suggests that it is faster than forkserver [1], and it is a fairly simple install. Apache.org is using it and processes quite a bit of mail. [1] http://osdir.com/ml/mail.qpsmtpd/2006-04/msg00035.html
Re: Performance / Tuning questions
I actually did a full testing of qpsmtpd-apache vs forkserver when I first started building this cluster and the apache version just had way to much overhead. Basically it couldn't handle the connections per second we were throwing it. I asked the list for some help at that time, as I was thinking my config could be off, but never really got any. I've got a test box going with 0.40 and the pre-fork server now and it seems much better. On 8/15/07 2:40 PM, Fred Moyer [EMAIL PROTECTED] wrote: Ed McLain wrote: Hello all, Got a quick question for all those out there running large setups using qpsmtpd. We currently have a setup which is load balanced across an several qpsmtpd servers running a custom linux distro that basically runs the entire setup in ram for maximum performance. Until lately the setup has been running absolutely wonderful but with all these spam bots running around I've started noticing some odd issues and I'm about to start pulling my hair out. I've tweaked and tweaked the sysctl vars for the network interfaces, disabled rdns, and also removed almost all of our plugins in an attempt to keep the machines running with the flood of incoming emails. My setup is as follows: Qpsmtpd v0.32 running with forkserver Maybe take Apache::Qpsmtpd for a spin. Anecdotal evidence suggests that it is faster than forkserver [1], and it is a fairly simple install. Apache.org is using it and processes quite a bit of mail. [1] http://osdir.com/ml/mail.qpsmtpd/2006-04/msg00035.html -- Ed McLain Sr. Data Center Engineer TekLinks, Inc. 205.314.6634 [EMAIL PROTECTED]
Re: Performance / Tuning questions
Ed McLain wrote: I actually did a full testing of qpsmtpd-apache vs forkserver when I first started building this cluster and the apache version just had way to much overhead. Basically it couldn't handle the connections per second we were throwing it. I asked the list for some help at that time, as I was thinking my config could be off, but never really got any. I've got a test box going with 0.40 and the pre-fork server now and it seems much better. Oh cool, good to know. I looked through the changes for 0.40 and didn't make the distinction between forkserver and pre-fork server until I read your response. Time for me to upgrade to 0.40!
Re: Performance / Tuning questions
Hello! But be careful - the 0.40 preforkserver version has MANY MANY BUGS!!! We tried to use it for about 500 servers with over 10 000 connections / 10 minutes - and it wasn't useable at all. We've now changed many lines - in the code and it works well. I've already posts some messages to the list but nobody seems to care - so ... Stefan Fred Moyer schrieb: Ed McLain wrote: I actually did a full testing of qpsmtpd-apache vs forkserver when I first started building this cluster and the apache version just had way to much overhead. Basically it couldn't handle the connections per second we were throwing it. I asked the list for some help at that time, as I was thinking my config could be off, but never really got any. I've got a test box going with 0.40 and the pre-fork server now and it seems much better. Oh cool, good to know. I looked through the changes for 0.40 and didn't make the distinction between forkserver and pre-fork server until I read your response. Time for me to upgrade to 0.40!
Re: Performance / Tuning questions
On Wed, 15 Aug 2007, Fred Moyer wrote: Maybe take Apache::Qpsmtpd for a spin. Anecdotal evidence suggests that it is faster than forkserver [1], and it is a fairly simple install. Apache.org is using it and processes quite a bit of mail. [1] http://osdir.com/ml/mail.qpsmtpd/2006-04/msg00035.html AFAICT, nobody has ever said what constitutes 'faster', or what performance testing has been done forkserver v Apache::Qpsmtpd.
Re: Performance / Tuning questions
I don't think the problem is that they don't care, I think the problem is that the patches get implemented into SVN but the there is no feature lock to the svn code for the bugs to get worked out on the base and with so many options finding all of the bugs is just a pain waiting to happen. Having a lot of different ways to run qpsmtpd is nice, but IMHO, having less options that are more stable and robust would be preferred. One other thing I'd like to add is that big groups like apache.org are running qpsmtpd, it would be nice to know how they have it setup, what patches they have applied, and all that so that the rest of us can get our setups working better and push qpsmtpd as a rock solid, spam fighting, performance oriented solution. Just my .02. On 8/15/07 4:45 PM, Stefan Priebe [EMAIL PROTECTED] wrote: I'm on holiday at the moment. I will send you them - when i'm back in 2 weeks. But would be more luckier, if yome of the devolopers seem to care. Cause qpsmtpd is a real great program i think... and it should be stable in a new release and not that buggy as it is... i think this is really sad / bad or whatever. Stefan Ed McLain schrieb: I'm all for any changes you have. I found most, I think, of the issues on our beta system had to do with some of the plugins, not sure though.. If you have any patches though I'd be open to trying to them out. I gotta do something. We currently have 8 3Ghz ( single cpu/dual core) boxes with 2GB of ram running 18-25 connections per second. With prefork I can steadily maintain 20 with a load average of 2, w00t. On 8/15/07 4:35 PM, Stefan Priebe [EMAIL PROTECTED] wrote: Hello! But be careful - the 0.40 preforkserver version has MANY MANY BUGS!!! We tried to use it for about 500 servers with over 10 000 connections / 10 minutes - and it wasn't useable at all. We've now changed many lines - in the code and it works well. I've already posts some messages to the list but nobody seems to care - so ... Stefan Fred Moyer schrieb: Ed McLain wrote: I actually did a full testing of qpsmtpd-apache vs forkserver when I first started building this cluster and the apache version just had way to much overhead. Basically it couldn't handle the connections per second we were throwing it. I asked the list for some help at that time, as I was thinking my config could be off, but never really got any. I've got a test box going with 0.40 and the pre-fork server now and it seems much better. Oh cool, good to know. I looked through the changes for 0.40 and didn't make the distinction between forkserver and pre-fork server until I read your response. Time for me to upgrade to 0.40! -- Ed McLain
Re: Performance / Tuning questions
On 15-Aug-07, at 5:35 PM, Stefan Priebe wrote: But be careful - the 0.40 preforkserver version has MANY MANY BUGS!!! We tried to use it for about 500 servers with over 10 000 connections / 10 minutes - and it wasn't useable at all. We've now changed many lines - in the code and it works well. I've already posts some messages to the list but nobody seems to care - so ... Honestly we do care, we just lack tuits. And people tend to work on stuff that's broken for them. Send me your updated qpsmtpd-prefork and I'll patch it in (save me digging patches out of the list). Matt.
Re: Performance / Tuning questions
On 15-Aug-07, at 5:39 PM, Ed McLain wrote: I'm all for any changes you have. I found most, I think, of the issues on our beta system had to do with some of the plugins, not sure though.. If you have any patches though I'd be open to trying to them out. I gotta do something. We currently have 8 3Ghz ( single cpu/dual core) boxes with 2GB of ram running 18-25 connections per second. With prefork I can steadily maintain 20 with a load average of 2, w00t. That's a pretty heafty setup. Async should be able to cope better, but it depends what you're doing in the plugins - you may need to write your own queue plugin for example. Feel free to email me off list if you wanna chat about it offline. Matt.
Re: Performance / Tuning questions
Ed McLain schrieb: I'm all for any changes you have. I found most, I think, of the issues on our beta system had to do with some of the plugins, not sure though.. If you have any patches though I'd be open to trying to them out. I gotta do something. We currently have 8 3Ghz ( single cpu/dual core) boxes with 2GB of ram running 18-25 connections per second. With prefork I can steadily maintain 20 with a load average of 2, w00t. If you are running that many boxes you might want to look at creating event based versions of your custom plugins and running the async server (Brad and Matt can evangelize that more than I). We were running upwards of 50 servers at my work that processed incoming mail, and I made a strong push for running qpsmtpd async there which unfortunately wasn't adopted for non-technical reasons :(
Re: Performance / Tuning questions
IS there any documentation anywhere on how and what needs to be changed? I've looked on the wiki and don't see anything on there about it. As an aside, I'll dig through the dnsbl plugin for async and see what I can come up with. Any information would be very helpful though. On 8/15/07 6:05 PM, Fred Moyer [EMAIL PROTECTED] wrote: Ed McLain schrieb: I'm all for any changes you have. I found most, I think, of the issues on our beta system had to do with some of the plugins, not sure though.. If you have any patches though I'd be open to trying to them out. I gotta do something. We currently have 8 3Ghz ( single cpu/dual core) boxes with 2GB of ram running 18-25 connections per second. With prefork I can steadily maintain 20 with a load average of 2, w00t. If you are running that many boxes you might want to look at creating event based versions of your custom plugins and running the async server (Brad and Matt can evangelize that more than I). We were running upwards of 50 servers at my work that processed incoming mail, and I made a strong push for running qpsmtpd async there which unfortunately wasn't adopted for non-technical reasons :( -- Ed McLain Sr. Data Center Engineer TekLinks, Inc. 205.314.6634 [EMAIL PROTECTED]
Re: Performance / Tuning questions
[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. -- Joe Schaefer
Re: Performance / Tuning questions
The problems I saw with Apache:Qpsmtpd were that the connections would get battered over each other. Basically, spammer connects and gets blacklisted, server drops the connection and takes a new one, new connections issues a HELO and server responds back with a 50x error message. The only way to fix this was to set the forking at a 1-1 rate, which just wasn't good obviously. Never had that problem with forkserver. On 8/15/07 6:14 PM, Joe Schaefer [EMAIL PROTECTED] 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. -- Ed McLain Sr. Data Center Engineer TekLinks, Inc. 205.314.6634 [EMAIL PROTECTED]
Re: Performance / Tuning questions
[EMAIL PROTECTED] (Ed McLain) writes: The problems I saw with Apache:Qpsmtpd were that the connections would get battered over each other. Basically, spammer connects and gets blacklisted, server drops the connection and takes a new one, new connections issues a HELO and server responds back with a 50x error message. Which (httpd) MPM were you running? I wouldn't recommend anything other than prefork in production. -- Joe Schaefer
Re: Performance / Tuning questions
On 15-Aug-07, at 7:08 PM, Ed McLain wrote: IS there any documentation anywhere on how and what needs to be changed? I've looked on the wiki and don't see anything on there about it. As an aside, I'll dig through the dnsbl plugin for async and see what I can come up with. Any information would be very helpful though. There isn't much documentation on it unfortunately. The big problem tends to be in the queue plugins as they do I/O - so for example in the postfix-queue plugin it opens a UNIX domain socket to the postfix queue daemon and squirts the message down that socket. All the time it is doing that, qpsmtpd-async could be processing other connections, but because it's not written in an async manner it can't. All you really need to do is create a subclass of Danga::Socket that does the same stuff Qpsmtpd::Postfix does, have the plugin return YIELD, and when the sending to postfix is complete run $qpsmtpd- run_transaction to finish up. I'm probably making it sound a bit simpler than it is, but all I mean is it's not a whole lot of work. If I had a postfix installation it'd be an afternoon's effort (but I don't have access to one). Matt
Re: Performance / Tuning questions
Hrmm.. I tried several different setups and configurations, rebuilding apache to support the different forking methods. It was so long ago though that I don't honestly remember which ones worked better or worse. On 8/15/07 9:10 PM, Peter Eisch [EMAIL PROTECTED] wrote: I don't see the behavior you describe. IfModule prefork.c StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0 /IfModule Child churn happens as a product of load over time, typically better than 1:1. peter On 8/15/07 6:17 PM, Ed McLain [EMAIL PROTECTED] wrote: The problems I saw with Apache:Qpsmtpd were that the connections would get battered over each other. Basically, spammer connects and gets blacklisted, server drops the connection and takes a new one, new connections issues a HELO and server responds back with a 50x error message. The only way to fix this was to set the forking at a 1-1 rate, which just wasn't good obviously. Never had that problem with forkserver. -- Ed McLain Sr. Data Center Engineer TekLinks, Inc. 205.314.6634 [EMAIL PROTECTED]
