At 06:38 PM 5/20/2004, you wrote:
Crew,
I reposrted this speed issue before, but despite very intensive debugging and testing, we have not found an external cause (meaning: not sniffer) for the following:
<snip/>
But, now comes the big mystery: when persistent mode is ON, it takes a lot more time to execute (while max polling is only 50ms!)
0,"2004-05-20 23:48:41",md50000845373.msg,827,812,15,0,0,0,3607,1
0,"2004-05-20 23:48:52",md50000845374.msg,842,812,0,0,0,0,3833,1
0,"2004-05-20 23:51:15",md50000845375.msg,936,874,0,0,0,0,9560,1
0,"2004-05-20 23:51:35",md50000845376.msg,889,859,15,0,0,0,26387,0
0,"2004-05-20 23:53:21",md50000845377.msg,937,922,0,15,0,15,1922,0
Which averages at 850 ms! While I expected 45 + 25 ms (to compensate for average waiting time) = 70 ms!
Pete, could you please check why this is happening (particularly in code OUTSIDE what's measured and logged)? I you can't find anything, I'll ask my collegue to come up with a timing program, which I would like to release on this list so other ppl can check how long it really takes to execute sniffer (measured from 'the outside').
As I recall when this last came up the solution turned out to be an on-access virus scanner that was introducing the extra delays. Turning off and/or adjusting the on-access virus scanner solved the timing problem.
The theory goes that the MDaemon CF is single threaded so when Sniffer runs normally there will only be one instance at once, and as a result each instance loads it's own rulebase and scans it's own message... this results in two file reads and no write operations.
With the persistent sniffer instance running as a server, there are several additional file creation, write, and access events per message. Each causes the on-demand scnner to intervene and thereby introduce the additional timing delays. The "transparent" way on-access virus scanners interfere with file operations accounts for the odd placement of the additional time.
... as I said, in theory ...
Hope this helps,
_M
