At 17:40 -0800 03/19/2005, jdow wrote:
There is a substantial hit, Vicki, on the order of a factor of two on my machines.
We are talking about Only when the Config File has Changed_. OK, so you get a factor of two, what, once a week?
Sendmail does this (you run newaliases or "make"to trigger it).
For clarity's sake, sendmail has real-time access to certain db files (like aliases.db which is generated by 'newaliases'). since sendmail has real-time access to these files, re-creating the .db file from the text version is all that is necessary.
However; if you make changes to the sendmail.mc file and the run make to create the sendmail.cf file, you still need to restart sendmail for it to read those changes.
SpamAssassin reads in all its config files into memory and has no real-time file access for configuration files.
I simply do not believe there can be a "substantial hit" if spamd re-reads the config file
Only When The Config File Has Changed
in order to read the config file in >only when it has been changed< you need to store state information somewhere (in memory or a real-time accessed db file, etc) for each config file. Since SA will read in /path/to/configfiles/*.cf there could be any number of files that state needs to be stored for. Also, to be prudent, state would also need to be stored for /usr/share/spamassassin/*.cf since some people will change those config files even against recommendations.
when fine-tuning for performance, even a call to stat() on a file or group of files can introduce performance hits. This is because it effectively still has to open and close the file-handle.
Then there's the matter of; in what way, and how often do you poll the .cf files to check for changes? that in itself could add a lot of overhead to the program that is unnecessary.
[..snip..]
alan
