> I posted a question two weeks ago asking if anyone knew a way > to calculate the amount of time it takes for individual > messages to clear the entire > receive/virusscan/junkmailscan/deliver process, and this > exactly why I asked. My system doesn't have any filters quite > as large as 140kb, or even 70k, but I keep adding steadily to > them and it "feels" like things are somewhat slower.
I suggest to simply try it out. Create a large filter list (definitively larger than you expect to use in future) and assign to all (random) keywords a weight of 0 and no additional action. This should create the same resource usage as with points. Now set up something to send a little bit more mails then your average mail processing rate (for example a Script sending out 20 messages as fast as possible) You can send it all to the same recipient. Imail/Decludes architecture will not process it faster because the messages are all the same. Put some tipical content (1 to 30 kB of text) in the message body. Watch the cpu usage during normal processing and the simulated mail bombardement. If you want you can also set a line PIDDEBUG ON In your global.cfg file This will write a .PID file for every declude process in you spool folder. Note: it's deleted after the process has finished his task so you have to open it during processing (not easy) In this PID file you can read in milliseconds how long any step takes to finish. All your results are something that can be interesting for multiple users on this list but keep in mind to indicate also what CPU, storage system, ... you've in use. Whats the average/peak message processing rate on your server, ... ------ About CPU usage: I've had an idea some months ago and still search someone who can help. The problem: certain spam-tests can be very CPU-intensive. This will prevent us to keep filter files and programming logic as simple as possible. (For example long text filter files, regular expressions) The real problem: Any mailserver running a lot of tests before store or forward the message to the final destination is much more vulnerable for peak usage or also simple mailbomb attacks then a MTA configured to simple deliver any message as fast and efficient as possible. The idea: If declude (or our external spamchk test) could determine an average CPU usage value before start all tests it should be possible to dinamicaly exclude certain resource intensive tests if the CPU average is to high. For example: In the global.cfg file a test could be configured like %75 MYFILTER filter d:\imail\declude\large_bodyfilter.txt x 5 0 This test would run only if declude has determined an average cpu usage below 75% Another problem: declude is called as needed for any single message. It's not a service running "around the clock" and so it's not able to determine and provide a reliable CPU average value. The solution: A small windows service that calculate and serves the 1, 5 or 10 minute CPU average value. Declude could connect over DCOM or a certain TCP/UDP port to this service before run all other tests. If the average is to high this will comment out automatically the "big tests". Such a solution will not decrease the detection rate because certain tests will not run sometimes, but will increase the detection rate because this new tests now can run everytime when it's possible. Markus --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.