David,

Am I to assume that the identifiers "SLOW server" and "FAST server" are completely relative to the amount of CPU utilization?  For instance, I have a very fast server, but it does a ton of work and can experience high CPU utilization, especially in spikes.  So is the trick here really just the CPU load?

Another question along these lines...High CPU utilization can happen on any server because of the burstiness of the traffic, and it is these high CPU utilization periods that really matter to people like myself as I could pretty much care less  about a 1 second delay on normal E-mail in comparison to processing a huge backlog of messages.  It would seem wise to then just leave the settings set for a heavily loaded server.

One alternative to manually specifying settings that are tied to notoriously bursty traffic would be to let the program manage this for us.  I believe that Sniffer does this for instance and maybe Pete will chime in, or maybe he has already in private.  It would seem that Declude could adjust things based on it's own spool of messages to process as these would be indicative of the traffic and the ability of a machine to handle that traffic.

Matt




David Barker wrote:
Different systems / configuration respond differently to these settings.  

In particular they to fine tune through-put with CPU utilization.

1. SLOW server that is heavily loaded 

You may want to try to increase WAITBETWEENTHREADS and lower THREADS.

2. FAST server 
Use the THREADS and WAITFORTHREADS to adjust the CPU utilization.

When decludeproc first starts up it will use a lot of the CPU but after that
the %CPU used by decludeproc should come way down. 

The %CPU of all processes running may be high depending on external tests,
other processes, etc.  If the system is spiking but coming down quickly
that's good.

David B
www.declude.com
 

When decludeproc first starts up it will use a lot of the CPU but once it
gets cooking the %CPU used by decludeproc should come way down. The %CPU of
all processes running may be high depending on external tests, other
processes, etc.  It the system is spiking but coming down quickly that's
good.

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Darrell
([EMAIL PROTECTED])
Sent: Thursday, September 22, 2005 11:51 AM
To: [email protected]
Subject: Re: [Declude.JunkMail] Declude Beta 3.0.4.4 Posted

David, 

Can you go over how you see them helping and what the positive benefit would

be in tweaking those values?  For example: by setting the WAITBETWEENTHREADS

to 1 second it will help by ..... 

Darrell 

David Barker writes: 

  
2 new Directives 

WAITFORTHREADS      1500
Located in the Declude.cfg - Defined in milliseconds eg. 1500 = 1.5
    
seconds
  
this can be changed so that when the maximum threads are in use this time
specifics the wait before checking to launch more threads. 	
	
WAITBETWEENTHREADS         1
Located in the Declude.cfg - Defined in milliseconds eg. 1 = 1 millisecond
The time to wait between spawning one thread and starting to process
    
another
  
thread. 

David B
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.
    
 


 ------------------------------------------------------------------------
Check out http://www.invariantsystems.com for utilities for Declude And 
Imail.  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.

---
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.


  

Reply via email to