On Wed, May 29, 2002 at 09:53:41AM -0700, Harry Putnam wrote: | dman <[EMAIL PROTECTED]> writes: [performance of SA] ... | > If you use the spamc/spamd combo instead, ... | > The resources needed for this setup is much lower than for running | > 'spamassassin' directly. ... | If you mean the entry in .procmailrc would be | UL=/usr/local/bin | :0fw | | $UL/spamc
Yes.
| But then it appears you have no access to the nifty flags like
| -p (point to prefs file), that are available to spamassassin
Yeah, that's because spamd has already started and read the prefs
files. In v 2.20 an option was made to allow spamd to read the user's
prefs (from $HOME/.spamassass/*.cf, I think).
That's really only useful on a multi-user system anyways. Since my
system is basically just me, I simply use
/etc/spamassassin/99_local.cf for all my "user" preferences.
| 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?
I guess the system-wide location of configs is hard-coded at build
time. I don't see any options in the manpage to specify. (in either
case you can always tweak the code to look in a different location, or
use symlinks)
| 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.
That's documenting the intent of the option. On a multi-user system,
not every user wants the same addresses in the whitelist. On a
single-user system the distinction is moot.
| 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
...
| And spamd started with `# spamd &'
|
| real 0m13.084s
| user 0m0.120s
^^^^^
| sys 0m0.110s
^^^^^
| The other way, shutting down spamd and with spamassassin in
...
| real 0m15.337s
| user 0m14.780s
^^^^^
| sys 0m0.260s
^^^^^
| Some 2.33 seconds
That's the "real" time. IOW how long you sat there waching the screen
before you saw a response from the program.
Notice that the CPU time used by the system while in "userland"
differs by 14.66 seconds (a factor of 123) and the CPU time used in
"system space" was cut by a factor of 2. spamd was mostly sitting
idle (letting your CPU do other, useful, stuff) while it was doing the
RBL checks and the kernel didn't have to work as hard (less loading of
programs and reading of files).
If you use the '-L' option to spamd to disable network (RBL, razor)
checks then the "real" time will drop down to be real close to the
"user+system" time.
| which may be quite a lot considering its only 3 messages
I usually see about 0-4 seconds of real time per message (using
spamd). I am using the RBL checks, and added some additional DNSBLs
to my config (and I'm running bind locally).
| but it also means that any way I run the program it is very
| expensive.
It does a lot of work, but for a mail server that isn't swamped, using
spamd is not very noticable.
HTH,
-D
--
There is not a righteous man on earth
who does what is right and never sins.
Ecclesiastes 7:20
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
msg05575/pgp00000.pgp
Description: PGP signature
