I am still working a problem at our hosting facility (a t1 is down) so it
will be a while before I can get back to the list, however I wanted to
clear this one up to minimize confusion.
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
