A persistent server instance uses a dynamic poll timing algorithm to minimize system loads while maximizing response times. It is probably not appropriate to use a fixed time interval for polling since this can cause unnecessary system loading and since the dynamic approach we're using has proven in our labs to offer improved all-around performance.
When the server has processed a job for a client it polls again immediately without waiting.
If no job is found then it will wait a short time before polling again.
If there are no available clients on a poll then the wait time between polls will increase in a "natural spiral" based on a Fibonacci sequence. This wait time will continue to expand until either a new job is found or the limit is reached. The limit is currently set to 1/2 the maximum client base wait time - which amounts to 4 seconds.
It's worth noting that in order for a server instance to get to a given wait time (such as 4 seconds) there must have been no messages to process for that amount of time. It's also worth noting that some folks using spamassassin regularly report message processing times on the order of 5 to 9+ full seconds for each message (I just read this on the sa list). Based on these two factors I've considered that waiting a maximum of 4 seconds to process a message after a 4 second lull in activity is probably not an issue - especially considering that once the message is processed it will likely take only an additional 30ms or so on average for a total of 4.030 sec (ymmv). This also represents the worst case given the current tuning parameters...
Once a job is found then the wait time is reset to the minimum.
Once again, the first poll after a job has been processed has no wait time... so if there is a burst of message activity after a 4+ second lull, the first message waits a maximum of 4 seconds and the rest wait only a few tens of milliseconds.
The monitor messages you are seeing are only a debugging/tuning aid and they will be removed for the production version. The timing message is only emitted when the server instance has found no messages to process during the previous poll.
Hope this helps, _M
PS: In a situation where peer-server instances become mixed it is possible for more than one server instance to become active for a period of time. The Fibonacci timing spiral helps to ensure a distributed scattering of lock requests when multiple instances are active - thus reducing collisions.
At 03:04 PM 3/17/2004, you wrote:
Pete,
After my previous message, I noticed that 'polling' really means that Sniffer is waiting that many milliseconds before it processes another e-mail.
If I'm seeing this correctly, I'd like to request another option available when spawning the persistent exe: /polling:x (where x = a fixed amount of milliseconds between polling)
Groet, (regards) ------------------------------------------ ing. Michiel Prins bsc [EMAIL PROTECTED] SOS Small Office Solutions / Reject / **** Wannepad 27 - 1066 HW - Amsterdam t.+31(0)20-4082627 - f.+31-(0)20-4082628 ------------------------------------------ Consultancy - Installation - Maintenance Network Security - Internet - E-mail Software Development - Project Management ------------------------------------------
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: woensdag 17 maart 2004 20:05 To: [EMAIL PROTECTED] Subject: [sniffer] Call for beta testers... snfrv2r3b1
Hello folks,
I know folks are anxious to get their hands on this version so I'm going to play this beta round a little looser than usual. Version 2-3b1 implements a persistent mode feature for our cellular peer-server technology. Launching a persistent instance of Message Sniffer has the effect of creating a daemon so that all other instances will elect to be clients. We observed a DRAMATIC improvement in system performance on our NT4/Imail/Declude test bed.
In static tests on my Toshiba 6100 we saw no memory leaks and consistent performance over the past 18+ hours of testing. This included several tests with more than 100+ concurrent client instances - all without failure and without making the system unresponsive (though the WinXP file system did start to show signs of strain).
This beta is for the windows platform only... once we're happy with this version will will make the source and *nix versions available as always.
Windows platform users who are interested in testing the new beta should download the following file:
http://www.sortmonster.com/MessageSniffer/Betas/snfrv2r3b1.zip
The file contains an executable and a short readme file.
We are going to be extremely busy for the next few hours so we won't be able to provide support on this until later this evening. We have many updates and rulebase mods to attend to at the moment since we shifted resources heavily toward development last evening and through the night...
The current spam storm continues to rage with more than 500 core rule-base changes yesterday alone!
Be careful. Backup your current production version. Watch carefully.
Enjoy :-)
_M
This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
--- This message has been scanned for spam and viruses by www.reject.nl
This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
