-----Original Message-----
From: procmail-bounces(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
[mailto:procmail-bounces(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE]On Behalf Of
Dallman Ross
Sent: Wednesday, November 24, 2004 3:19 PM
To: procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
Subject: Re: Some ideas to improve performance
On Wed, Nov 24, 2004 at 02:13:29PM -0800, Gary Funck wrote:
I just did a little timing experiment. On an SGI Octane (roughly
equivalent to a 500Mhz Pentium, I'd guess), a simple formail -s
ran at a rate 484 messages per second. Adding the overhead of forking
procmail (formail -s procmail -m /dev/null < in_file > /dev/null)
dropped the message throughput to 80 messages per second. From this
we can conclude that there would be a noticeable improvment in
performance if procmail was able to do its own mbox splitting.
I think you're assuming a lot. For instance, you're assuming that
we will be utilizing this capability often enough to make it pay
off against all the thousands of other times that we are just using
procmail straight-up, no splitting needed. Procmail has to be read
into memory, and it's niche and tiny and tidy right now.
My assessment was technical only: having procmail split its own mail out
would likely offer noticeable performance improvements over the
'formail -s procmail' combo that we use today. Frequency of use and
complexity trade-offs were beyond the scope of this study. <g>
I agree that from a system-wide perspective that if one wanted to
improveme procmail performance, the engineering effort would be
better applied to looking at how procmail is used most of the time:
one-message-at-a-time delivery. And even then, it isn't clear that
procmail (or its interpretive overhead) is a bottleneck. In my set
up, procmail runs spamassassin on each mail that wasn't filtered
into its own mbox. SA _is_ slow: probably running at rates as low
as 3 messages per second on fairly fast hardware. This situation
can be improvemed by using spamd/spamc, but SA is still has a 10x or
higher cpu processing time than procmail.
I did ponder at one the possible benefits of folding formail, procmail,
and lockfile into a 'busy box' sort of combo. This would do little
harm to program modularity and would offer benefits when procmail
invokes formail and formail invokes procmail for example.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail