The problem with this architecture is that when it moves a batch of
messages into the work folder for processing, it quickly pegs the
processor at 100% as it launches all of the threads, but most messages go
through all of the steps quickly so the processors sit almost idle while
it is waiting for DNS lookups and virus scanning (which I do after JM).
Here's a sample of my combined CPU graph showing the pattern that this
creates:
I commented along time ago about this. Declude does give you options to
work with this. Essentially changing your WAITBETWEENTHREADS setting works
around this fairly decent. I use it to give just a bit of time between each
of the threads to prevent (50+ external programs from being called at once.
Now as you tweak that setting and others you will give yourself a more
predictable cpu curve line. By tweaking the settings you can keep
decludeproc processing messages and hopefully never entering the
"WAITFORMAIL" cycle.
Darrell
-------------------------------------------
Check out http://www.invariantsystems.com for utilities for Declude, Imail,
mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI
integration, MRTG Integration, and Log Parsers.
---
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.
