RE: Re[2]: [sniffer] Sniffer taking a long time?

2005-08-03 Thread Dan Horne
Thanks, I will do that. 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew
> Sent: Wednesday, August 03, 2005 3:17 AM
> To: sniffer@SortMonster.com
> Subject: RE: Re[2]: [sniffer] Sniffer taking a long time?
> 
> > So basically, what you are saying is that my volume is 
> really too low 
> > to take advantage of the persistent sniffer (and such may actually 
> > decrease my performance), and I should stick with the non-service 
> > version.  Is that right?  That is about what I thought (without the 
> > details of how sniffer works, I just wanted to be sure).
> 
> Well, Dan, for the inevitable rush of traffic, I'd stick with 
> the persistent sniffer implementation now that you have it working.
> 
> If the 2 second wait time galls you, then use your **.cfg 
> file and specify the
> 
> MaxPollTime: 500
> 
> value at 500 ms or whatever you'd like your maximum wait time 
> to be instead of 2 seconds (2000 ms).
> 
> Andrew 8)
> 
> 
> 
> 
> 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


RE: Re[2]: [sniffer] Sniffer taking a long time?

2005-08-03 Thread Colbeck, Andrew
> So basically, what you are saying is that my volume is really 
> too low to take advantage of the persistent sniffer (and such 
> may actually decrease my performance), and I should stick 
> with the non-service version.  Is that right?  That is about 
> what I thought (without the details of how sniffer works, I 
> just wanted to be sure).

Well, Dan, for the inevitable rush of traffic, I'd stick with the
persistent sniffer implementation now that you have it working.

If the 2 second wait time galls you, then use your **.cfg file and
specify the

MaxPollTime: 500

value at 500 ms or whatever you'd like your maximum wait time to be
instead of 2 seconds (2000 ms).

Andrew 8)




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


RE: Re[2]: [sniffer] Sniffer taking a long time?

2005-08-02 Thread Dan Horne
So basically, what you are saying is that my volume is really too low to take 
advantage of the persistent sniffer (and such may actually decrease my 
performance), and I should stick with the non-service version.  Is that right?  
That is about what I thought (without the details of how sniffer works, I just 
wanted to be sure).

Thanks, Pete.

Dan Horne

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil
> Sent: Tuesday, August 02, 2005 4:09 PM
> To: Dan Horne
> Subject: Re[2]: [sniffer] Sniffer taking a long time?
> 
> After following through all of this and looking at the .stat 
> file, I think I see what's going on.
> 
> Now that it is running and producing a .stat file, the flow 
> rate is very low. According to the stat data, about 6 msgs / minute.
> 
> Note the poll and loop times are in the 450 - 550 ms range.
> 
> SNF with the persistent engine is built for high throughput, 
> but it's also built to play nice.
> 
> The maximum poll time gets up to 2 seconds or so (sound familiar?)
> 
> If there are no messages for a while, then everything slows 
> down until the first message goes through. For that first 
> message, the SNF client will probably wait about 2 seconds 
> before looking for it's result because that's what the stat 
> file will tell it to do.
> 
> Since the next message probably won't come around for a few 
> seconds, that next message will probably wait about 2 seconds also.
> 
> If you were doing 6 messages a second then all of the times 
> would be much lower and so would the individual delays.
> 
> When you turn off the persistent instance, each new message 
> causes a client to look and see if there are any other peers 
> acting a servers... Since the messages are far and few 
> between, the client will elect to be a server (momentarily), 
> will find no work but it's own, will process it's own message 
> and leave. -- This is the automatic peer-server mode. It will 
> always work like this unless more than one message is being 
> processed at the same moment.
> 
> In peer-server mode, since there is nothing else going on and 
> no persistent instance to coordinate the operations, each 
> message will get processed as fast as the rulebase can be 
> loaded and then the program will drop.
> 
> When the persistent instance is introduced, it sets the pace 
> - and sicne there are no other messages, each client will 
> wait about 2 seconds (or half a second or so with the .stat 
> file contents you show) before it begins looking for it's results.
> 
> The server instance will also wait a bit before looking for 
> new jobs so that the file system isn't constantly being scanned.
> 
> Of course, if a burst of messages come through then the 
> pacing will speed up as much as necessary to keep up with the volume.
> 
> Hope this helps,
> 
> _M
> 
> On Tuesday, August 2, 2005, 3:38:52 PM, Dan wrote:
> 
> DH> No, I followed your instructions exactly (and not for the first 
> DH> time).  I didn't add those extra values until today.  Prior to  
> DH> adding the AppDirectory value, the service was taking a minute to 
> DH> scan emails;  after adding it the scan time went to around 2 
> DH> seconds.  I can't get it any  lower than that.  Initially 
> mine was 
> DH> set up exactly as you said, with only  "Application" 
> containing the 
> DH> path, authcode and persistent.  Today after  hearing no 
> suggestions 
> DH> from the list, and based on recent list messages 
> mentioning the home 
> DH> directory for the service, I looked at the srvany.exe 
> doco  to find 
> DH> out how to give it a home directory.
> DH> That's when I added  AppDirectory.  I also saw and added 
> DH> AppParameters at the same time and  added those as well, 
> though they 
> DH> seem not to be needed.
> DH>  
> DH> Prior to adding the AppDirectory value, I never got any 
> .stat file 
> DH> or any .SVR file in my sniffer dir.  After adding that value and  
> DH> starting the service those files appeared.
> DH>  
> DH>  
> 
> 
> DH> From: [EMAIL PROTECTED]
> DH> [mailto:[EMAIL PROTECTED] On  Behalf Of Matt
> DH> Sent: Tuesday, August 02, 2005 3:24  PM
> DH> To: sniffer@SortMonster.com
> DH> Subject: Re: [sniffer]  Sniffer taking a long time?
> 
> 
>   
> 
> DH> Dan,
> 
> DH> There is no AppDirectory value on my servereither.  The
> DH> Parameters key has only one value under it besides Default   
> DH> which is "Application", and it contains exactly what I provided
> DH> below.   

Re[2]: [sniffer] Sniffer taking a long time?

2005-08-02 Thread Pete McNeil
After following through all of this and looking at the .stat file, I
think I see what's going on.

Now that it is running and producing a .stat file, the flow rate is
very low. According to the stat data, about 6 msgs / minute.

Note the poll and loop times are in the 450 - 550 ms range.

SNF with the persistent engine is built for high throughput, but it's
also built to play nice.

The maximum poll time gets up to 2 seconds or so (sound familiar?)

If there are no messages for a while, then everything slows down until
the first message goes through. For that first message, the SNF client
will probably wait about 2 seconds before looking for it's result
because that's what the stat file will tell it to do.

Since the next message probably won't come around for a few seconds,
that next message will probably wait about 2 seconds also.

If you were doing 6 messages a second then all of the times would be
much lower and so would the individual delays.

When you turn off the persistent instance, each new message causes a
client to look and see if there are any other peers acting a
servers... Since the messages are far and few between, the client will
elect to be a server (momentarily), will find no work but it's own,
will process it's own message and leave. -- This is the automatic
peer-server mode. It will always work like this unless more than one
message is being processed at the same moment.

In peer-server mode, since there is nothing else going on and no
persistent instance to coordinate the operations, each message will
get processed as fast as the rulebase can be loaded and then the
program will drop.

When the persistent instance is introduced, it sets the pace - and
sicne there are no other messages, each client will wait about 2
seconds (or half a second or so with the .stat file contents you show)
before it begins looking for it's results.

The server instance will also wait a bit before looking for new jobs
so that the file system isn't constantly being scanned.

Of course, if a burst of messages come through then the pacing will
speed up as much as necessary to keep up with the volume.

Hope this helps,

_M

On Tuesday, August 2, 2005, 3:38:52 PM, Dan wrote:

DH> No, I followed your instructions exactly (and not for the 
DH> first time).  I didn't add those extra values until today.  Prior
DH> to  adding the AppDirectory value, the service was taking a minute
DH> to scan emails;  after adding it the scan time went to around 2
DH> seconds.  I can't get it any  lower than that.  Initially mine was
DH> set up exactly as you said, with only  "Application" containing
DH> the path, authcode and persistent.  Today after  hearing no
DH> suggestions from the list, and based on recent list messages 
DH> mentioning the home directory for the service, I looked at the
DH> srvany.exe doco  to find out how to give it a home directory. 
DH> That's when I added  AppDirectory.  I also saw and added
DH> AppParameters at the same time and  added those as well, though
DH> they seem not to be needed.
DH>  
DH> Prior to adding the AppDirectory value, I never got any 
DH> .stat file or any .SVR file in my sniffer dir.  After adding that
DH> value and  starting the service those files appeared.
DH>  
DH>  


DH> From: [EMAIL PROTECTED]
DH> [mailto:[EMAIL PROTECTED] On  Behalf Of Matt
DH> Sent: Tuesday, August 02, 2005 3:24  PM
DH> To: sniffer@SortMonster.com
DH> Subject: Re: [sniffer]  Sniffer taking a long time?


  

DH> Dan,

DH> There is no AppDirectory value on my servereither.  The
DH> Parameters key has only one value under it besides Default   
DH> which is "Application", and it contains exactly what I provided
DH> below. Could it be that you tried to hard to get everything
DH> right by tweaking theseadditional keys?

DH> Something else.  Did you make sure that theSniffer
DH> service that you created was started?  No doubt it will work if   
DH> you follow those directions to a T, and there aren't any issues
DH> with yourserver apart from this.

DH> Matt



DH> Dan Horne wrote: 
  


DH>   I removed the AppParameters value and put the authcode 
DH> and persistent back in the Application value where it was before. 
DH> It  didn't make any difference at all in the processing time,
DH> still right around  2 seconds.  I don't know how your setup is
DH> working without at least the  AppDirectory value, because mine
DH> didn't start working until I put that in,  but if it is, I
DH> can't argue.  My server load isn't anywhere near yours,  so I
DH> don't see what the problem could be with mine.  Oh well, unless   
DH> Pete responds with a suggestion, I guess I'll just keep using the 
DH> non-service version.
DH>    
DH>   Thanks anyway.


  

DH>   From:[EMAIL PROTECTED]
DH> [mailto:[EMAIL PROTECTED] On Behalf Of Matt
DH> Sent: Tuesday, August 02, 2005 2:37PM
DH> To:sniffer@SortMonster.com
DH> Subject: Re: [sniffer] Sniffer taking a longtime?


DH> Dan,

DH> 

RE: Re[2]: [sniffer] Sniffer taking a long time?

2005-08-01 Thread Dan Horne
I replied to an off-list message from Pete, but for completeness, I will
repost it to the list.  We can keep it on the list, Pete, if that does
ya'.  It looks like Pete is probably right in that the service is
probably not loading correctly for some reason.  There is no .stat file
in my sniffer directory.  Here are my responses to Pete's questions:

> Can you please tell me the content of your .stat file.

There is no .stat file in my sniffer directory.  No file ending with
.stat, either.

> 
> Can you estimate the number of messages per minute that you are 
> processing?

Fairly low volume, I guess, around 10 messages per minute.
 
> Do you have a lot of extra files in your sniffer directory?

Yes, there are tons of old *.FIN files, *.WRK files, *.XXX files, *.ERR
files, and a few *.ABT files.  However they are mostly old files.
Sorting by date, I can see several *.FIN files, but they don't hang
around long.  There are several still there from each day though (I
assume due to daily scheduled reboots according to the timestamp).  The
last occurrences of the other files by extension are:

*.XXX - 7/24/2005
*.ERR - 4/27/2005
*.ABT - 2/4/2005
*.WRK - 12/14/2004

I assume it is ok to delete all these?

> Does you have a lot of fragmentation in your file system? How do you 
> mitigate the fragmentation you do have?

No, we defrag daily after hours using Diskeeper's smart scheduling.

> This information will help.
> 
> Thanks,
> 
> _M
> 

NP.  I'm sure you saw my other posts to the list, but I'll recap.  When
I stop the service, processing time goes down to milliseconds.
Reenabling the sniffer service (installed per the archived instructions
using srvany.exe) causes the processing time to go back up into the
minute per message range.  I have the service disabled for now.  We
moved our Imail/Declude install off to a weaker machine a couple weeks
ago in prep for replacing it with Suse Linux ES running postfix (and
sniffer, of course) on the more powerful hardware.  Because the current
computer is not as powerful and has become backed up a few times, I was
looking at ways to lower the CPU cost per message when I found this. 


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


Re[2]: [sniffer] Sniffer taking a long time?

2005-08-01 Thread Pete McNeil
It seems that we'll need more information to understand what's
happening here.

In some cases, for example, a message might give up waiting for the
persistent instance to handle it's message - then it will load the
rulebase and process the message itself.

I can't be completely sure based on the information you've provided so
far, but it seems like that might be the case. That is - for the
message in question - it waited close to a minute and then processed
the message itself.

The persistent instance should be publishing a .stat file if it is
working properly. You can periodically "type" this file at the dos
command line to see real-time data on the load and timing parameters.

This information would help.

Thanks,

_M

On Monday, August 1, 2005, 3:40:18 PM, Dan wrote:

DH> More info:  When I stop the Sniffer service, processing time goes to
DH> milliseconds.  Start the service back and it is back up to a minute.

>> -Original Message-
>> From: [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne
>> Sent: Monday, August 01, 2005 11:58 AM
>> To: sniffer@SortMonster.com
>> Subject: RE: [sniffer] Sniffer taking a long time?
>> 
>> Here are the sniffer log entries for each of the messages, if 
>> that helps
>> any:
>> 
>>  
>> > 08/01/2005 11:32:51.747 Q40a201cc1a59 SNIFFER: External program
>> > started: M:\IMail\Sniffer2\Distribution\Winx\mysniffer.exe
>> > mysnifferauthcode S:\imail\spool\D40a201cc1a59.SMD
>> > 08/01/2005 11:33:46.751 Q40a201cc1a59 SNIFFER: External program
>> > reports exit code of 61
>> 
>> 20050801153252D40a201cc1a59.SMD   70  20  
>> Match 266707
>> 61343 358 50
>> 20050801153252D40a201cc1a59.SMD   70  20  
>> Match 426427
>> 611915192950
>> 20050801153252D40a201cc1a59.SMD   70  20  
>> Final 266707
>> 610   502050
>>  
>> 
>> > 08/01/2005 11:30:53.757 Q402b01b61a28 SNIFFER: External program
>> > started: M:\IMail\Sniffer2\Distribution\Winx\mysniffer.exe
>> > mysnifferauthcode S:\imail\spool\D402b01b61a28.SMD
>> > 08/01/2005 11:31:48.210 Q402b01b61a28 SNIFFER: External program
>> > reports exit code of 52
>> 
>> 20050801153054D402b01b61a28.SMD   80  10  
>> Match 372669
>> 522745286060
>> 20050801153054D402b01b61a28.SMD   80  10  
>> Match 423177
>> 612695303660
>> 20050801153054D402b01b61a28.SMD   80  10  
>> Match 372652
>> 612695313860
>> 20050801153054D402b01b61a28.SMD   80  10  
>> Final 372669
>> 520   495260
>>  
>> > 08/01/2005 11:30:56.561 Q402a01cc1a27 SNIFFER: External program
>> > started: M:\IMail\Sniffer2\Distribution\Winx\mysniffer.exe
>> > mysnifferauthcode S:\imail\spool\D402a01cc1a27.SMD
>> > 08/01/2005 11:31:51.074 Q402a01cc1a27 SNIFFER: External program
>> > reports exit code of 0
>> 
>> 20050801153056D402a01cc1a27.SMD   190 40  
>> White 137999
>> 0 2256228544
>> 20050801153056D402a01cc1a27.SMD   190 40  
>> Final 137999
>> 0 0   24419   44
>> 
>> 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
>> 

DH> This E-Mail came from the Message Sniffer mailing list. For
DH> information and (un)subscription instructions go to
DH> 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