Any one else notice...

[Ron Broersma]

I've been watching this thread with interest as I've also noticed a
recent slowdown.  I didn't correlate it with one of the version updates
because I've been changing a number of things and wasn't sure what
caused the change in performance.  I put many timing measurements in the
code and the bulk of the delays are in spamassassin.  Since I couldn't
immediately find what was to blame, I've had to "throw hardware at the
problem" to get some performance back.

In the process, I've gathered some performance statistics on a number of
machine configurations which may be useful to others, so I share them here:

The machine configs are as follows:  (all running Red Hat Linux 7.2 or 7.3)
A:    Pentium II, 400 Mhz
B:    AMD Athlon, 900 Mhz
C:    Compaq - dual Pentium III, 550 Mhz each (smp kernel)
D:    AMD Athlon, dual 1400 Mhz (smp kernel)

Under heavy load, this is the average performance that I see with the
current version of mailscanner:
A:    0.64 messages/sec
B:    1.25 messages/sec
C:    1.35 messages/sec
D:    3.25 messages/sec

Other configuration info:  We use McAfee for virus checking, not Sophos.
 We use MAPS-RBL+, checked in mailscanner, not in spamassassin.  Deliver
In Background = yes.  We process around 140,000 messages per day on this
server.  So, your performance may vary depending on your local
configuration and the types of traffic through your server.

There was a suggestion to change the max number of messages per pass
from 100 to 15.  I tried that and it made absolutely no difference in
overall performance.

If there is a strong concensus that the slowdown is due to some change
related to a recent mailscanner upgrade, I can go back to 3.14-1 or
3.13-2 as a test and see how the numbers compare.

--Ron

Julian Field wrote:

> I really want to track this down.
>
> So if you fancy adding a few "print STDERR" commands to the code, if
> you're
> confident to do it, and can help work out where the timing difference is,
> it would really help me.
>
> There is a possible cause in the spam checking (caused by forking to
> implement RBL timeouts), so make sure that "Spam Checks = no" for
> starters.
>
> We need to compare a system under real load, with the ability to switch
> versions quite easily, to help solve this. All help would be much
> appreciated!
>
> Jules.
> --
> Julian Field                Teaching Systems Manager
> jkf at ecs.soton.ac.uk         Dept. of Electronics & Computer Science
> Tel. 023 8059 2817          University of Southampton
>                             Southampton SO17 1BJ