I am considering all of the options that have been suggested. It is likely that tuning parameters will be implemented in a configuration file rather than as command line options.
Perhaps our messages crossed in the ether, or perhaps there is still confusion on the polling times.
Part of the confusion may be that the Polled waited: xx message is displayed only after an empty poll has been returned. When there are messages to process there is no delay and there is also no message produced.
Polling times by default are zero ms after completing a job, then with each empty poll the time is extended up to a maximum of 4 seconds. The only way the poll time is increased is when there are no messages to process. Once a message arrives, the next poll will be immediate... followed by a poll after a short wait, then longer, etc.
Currently this is how the "natural spiral" expands.
0 ms - First poll after a job.
30 ms poll wait, 30ms total - Second poll after no jobs found.
60 ms poll wait, 90ms total - Third poll after no jobs found.
90 ms poll wait, 180ms total - Fourth poll after no jobs found.
150 ms poll wait, 330ms total - Fifth poll after no jobs found.
240 ms poll wait, 570ms total - Sixth poll after no jobs found.
390 ms poll wait, 960ms total - Seventh poll after no jobs found.
630 ms poll wait, 1599ms total - Eighth poll after no jobs found.
1020 ms poll wait, 2619ms total - Ninth poll after no jobs found.
1650 ms poll wait, 4269ms total - Tenth poll after no jobs found.
2670 ms poll wait, 6939ms total - Eleventh poll after no jobs found.
4320 ms poll wait, 11259ms total - Twelfth poll after no jobs found.
4000 ms poll wait, 15259ms total - All subsequent polls when no jobs are present.
According to this - if it takes a second (960ms) for a new message to arrive, then it will only take half a second (630ms) at most for the persistent server to pick up that message and process it.
With MDaemon's single threaded content filter, If a new message is delivered for processing within 30ms, then the most time it will take for the message to be picked up is 30ms. If it takes MDaemon up to 90ms to deliver the next message then it will be picked up within 60ms or less... and so on.
The only time the persistent server waits is when there are no messages to process. Once messages arrive they are processed as quickly as possible.
All of these parameters will eventually be tunable though that should not be necessary in most cases.
Hope this helps, _M
PS: After missing an earlier window, we had been told that we would be integrating Message Sniffer into MDaemon in March. After many months of preparation and anticipation, Arvel suddenly decided not to integrate the Message Sniffer engine into MDaemon, instead preferring to stick with SpamAssassin alone citing a desire to avoid "third party" integration.
Clearly, integrating the Message Sniffer engine directly would have been the best approach, but I was unable to convince Arvel to move forward - even after waiving all fees and providing an option to ship MDaemon with the demo rule-base pre-installed and automatically updated.
In any case we will be making continuous improvements to Message Sniffer so that we can get around the limitations in MDaemon and support our clients who use MDaemon. Perhaps at some point in the future Arvel will reconsider this decision and if so we will offer our full support.
In the mean time we have a working integration using the Content Filter, and we also have an alternative where Message Sniffer can be integrated into Spam Assassin directly:
http://www.sortmonster.com/MessageSniffer/Installation/SpamAssassin.html
MDaemon CF info:
http://www.sortmonster.com/MessageSniffer/Installation/MDaemon.html
At 02:59 AM 3/18/2004, you wrote:
Paul,
Aren't you having problems that the polling times just make the waiting times in the CF longer? While normally my bottleneck was the loading of the rulebase, now it's the polling time which is way longer.
Pete,
With Mdaemon, where there's only one message being processed at a time, and there's no multithreading content filter yet, I would like to be able to set polling time to a fixed 25 or 30 ms. Normally, loading the rulebase would take 200, with polling I understand this could be reduced to 30 ms -> if the time can be set to a fixed ms.
Could you also consider the other options I asked?
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 Peer-to-Peer, LLC Sent: donderdag 18 maart 2004 4:21 To: [EMAIL PROTECTED] Subject: RE: [sniffer] Call for beta testers... snfrv2r3b1
_M,
FYI: Have been running the beta ver 2.3b1 on MDaemon 7.0.0 for several hours now and all is stable. Everything is performing as advertised...
paul roulier
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Wednesday, March 17, 2004 2:05 PM 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 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
