Mark Martinec wrote: > >> I didn't understand this. Why should have a little effect on troughput? >> If a mail is processed in 3s instead of 15s (apart concurrent sending), >> means that I can deliver 20 mail/min, instead of 4 mail/min. If I have >> 8 processes|core then I can deliver 20*8 mail/min instead of just 4*8. >> > > SpamAssassin's bottleneck is mainly the CPU. Say for example that > it takes 10 seconds to process a message, including all the network > wait times. Say that 1 second is used for crunching and 9 seconds > are wait times. To fully saturate your CPU resources, it would take > 10 parallel child processes, which would yield an aggregate mail > throughput of 1 message per second (0.1 * 10). > > Now, if network wait times (latencies) would be shrunk to 0 wait time, > leaving 1 second for crunching, it would take one child process to > fully saturate the CPU, and would again yield a 1 message/s rate. > Adding more child processes would achieve nothing, the throughput > can not go beyond CPU saturation point. > OK, though those value are achievable setting several processes in parallel to to exploit the wait times, but this would need that you have your mailserver feeded at highest possible ratio (I test this using fetchmail and downloading a folder full of spams so reinjecting it to the mail system), while my request of stats was indeed about evaluate peak rate for single process/thread, or rather the minimal delivery delay: I mean this: if on average processing a mail takes 30 seconds, and your system is capable of sustaining 100 parallel process, doesn't mean the initial email is received after 30/100 seconds, but always after 30 seconds it was received.
>> Or should this be handled trough custom policy banks + XFORWARD >> (and can $sa_local_tests_only = 1; be local to a single policy bank)? >> > > Unfortunately the $sa_local_tests_only can not be changed by a > policy bank, because SpamAssassin wants this information during > BTW, FYI turning default $sa_local_tests_only to 1, the processing time reported from the amavis agent dropped from 7-15 s/msg to 0.2s/msg (with TimeElapsedSpamCheck around 0.103 s/msg), so definitively the network tests are what eats more. I wonder if someone experienced better results with network test enabled but with some good DNS caching (so I wonder why my bind dns cache doesn't give much boosts)... Bye Giuseppe. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
