Troubleshooting Slow App. w/ Sniffer

[laobancha]

I would like to know what anyone suggestions would be for troubleshooting the slow application with the sniffer. Also in case we never had monitoring and troubleshooting system deployed ever before.
? approaches
? sniffer positioning and capturing points

Any helps would be appriciated. Thanks.

 

[laobancha]

sorry for my mistake -- dupliated thread.

 

[wybnormal]

Learn about absolute time, delta time and how to set the marker on an interesting packet that marks the beginning of the data stream.

Get the sniffer as close to the server as you can.. either monitor the port(cisco equipment) or break into the link using a HUB.. not a switch, a HUB. run a trace where you catch everything to and from that server. Once it's caught you can gen a baseline of traffic. Catch it at a few different times during the day. I have cuaght un-authorized backups running before during the middle of the day blowing servers performance. If you see something interesting ... liek the data you want.. build a filter to watch that traffic and run another trace. Pay attention to the times. You can tell if the packet is slow from the server, slow from the client, the handshake between client and server are fine but one of the sits on the packet too long and so on.

Check out

http://www.packet-level.com

for good info on network analysis.


MikeS Find me at

http://www.packetattack.com

"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu

 

[Sniff4Food]

You should also position the Sniffer next to the client. Bearing in mind that the delta times MikeS suggested your looking at are when those frames passed by the Sniffer, not when the client sent and received the information. By sniffing near the client you will get a better feel for the user's experience. If the issue is a slow link between the client and server, sniffing by the server will not show you that.

However if the issue is the application itself, sniffing next to the server will show the request going to the server, the server holding it, and then the response. You can then go to the Developer "What is it DOING in there?" ie, it is not the "network's fault".
Life is different in BettyLand

 

[laobancha]

Thank you a lot for every suggestions.
As your mention, I should place the sniffer next to the server in order to how fast it responses for a command. So that I have to select and match a pair of Command/Response right and find its delta time. I wonder how accurate if, instead, I measure 90% responses with ART at the same Sniffer position, or even next to the client at the same time. What do you think?

 

[Sniff4Food]

If you have two Sniffers, by all means have one at the client and one at the server for comparison. Otherwise, move back and forth between the client and server. If the response time is fast next to server, but slow to the client, the latency is being induced by the network. If slow sniffing by the server, it is the application (or the server itself), especially easy to "prove" if there is a tcp ack and then much later, the response is sent.

You are right, you will have to match C/R pairs in the decode tab to look at delta times. Using ART will make this infinitely easier. I would look at average response time though, vs. the 90%. That is just personal preference. I like to see the whole picture. If the port number of the application is not a "well known" you can always add it in Tools, Options, Protocols, and then to ART's properties. Life is different in BettyLand