dman <[EMAIL PROTECTED]> writes:
> It is normal for the way you're running SA. The way you're using it
> (by running 'spamassassin'), for each message :
> o start a perl process (not cheap)
> o compile lots and lots of regexes (takes lots and lots of CPU)
> o do the regex matches
> o a bit of I/O too
>
> If you use the spamc/spamd combo instead, you perform the first 2
> steps only once. Then for each message you are starting just a spamc
> process (much lighter weight than perl) and using the regexes that are
> already compiled and in memory. The resources needed for this setup
> is much lower than for running 'spamassassin' directly. (the setup is
> also trivial to manage -- just run 'spamd' first (or
> /etc/init.d/spamassassin if you use debian) and then run 'spamc' in
> place of 'spamassassin')
If you mean the entry in .procmailrc would be
UL=/usr/local/bin
:0fw
| $UL/spamc
But then it appears you have no access to the nifty flags like
-p (point to prefs file), that are available to spamassassin
UL=/usr/local/bin
:0fw
| $UL/spamc -D -P -p /etc/mail/spamassassin/user_prefs
-D is avalable with spamd but not the others. So how do you point
spamd at a system wide user_prefs? Maybe just put the
whitelist_from stuff in /etc/mail/spammassassin/local.cf? But the
docs do say that whitelist stuff is to go in user_prefs.
Testing this out by starting spamd and putting spamc in place of
spamassassin in .procmailrc (with no flags) shows a little improvement
but not much.
I'm catting only 3 messages through procmail
time cat tcron| formail -e -s procmail -m ${HOME}/projects/proc/trc
where trc contains:
UL=/usr/local/bin
:0fw
| $UL/spamc
:0:
* ^X-Spam-Status: Yes
spam
And spamd started with `# spamd &'
real 0m13.084s
user 0m0.120s
sys 0m0.110s
The other way, shutting down spamd and with spamassassin in
promailrc, where trc contains:
UL=/usr/local/bin
:0fw
| $UL/spamassassin -D -P -p /etc/mail/spamassassin/user_prefs
:0:
* ^X-Spam-Status: Yes
spam
real 0m15.337s
user 0m14.780s
sys 0m0.260s
Some 2.33 seconds which may be quite a lot considering its only 3
messages but it also means that any way I run the program it is very
expensive.
It should be noted though, that no attempt to control other processes
was made so the results are not very reliable.
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
