SQL Packet Analysis Using Dynamic Baselining
Comparing a good and bad trace helps identify performance issues. Dynamic baselining can be used when you do not have a good trace to reference.
February 8, 2019
Packet analysis can be very overwhelming since there are many things to keep in mind as you go through a trace file.
Like any application, several servers and protocols have to work together to get the job done. Unfortunately, it can be very difficult to figure out which server, protocol or application is the source of your issues.
In this example, a client was complaining about application performance. We installed Wireshark (www.wireshark.org) on their desktop and asked them if they could reproduce their issues. We got lucky and captured what they considered to be ‘slow’ performance.
One of the first things I do when analyzing a trace file like this is to look for any common issues that would cause performance issues. Here is a quick list of some of the things I look for:
Name server performance issues (DNS, LDAP, WINS)
Small packets used during hi volume transactions
TCP retransmissions
UDP dropped packets
ICMP or application ERROR messages
Excessive delays
That last one “Excessive Delays” is a tough one. Ideally, you want to compare a good and bad trace. So, what do you do when you do not have a baseline or good trace to reference?
That’s what I cover in the video as well as how to configure your protocol analyzer.
Please keep in mind where the trace was taken. In this case, it was from the client. If we see delays from the server, keep in mind it may not be the server, it could be anything between the client and the server. If we had the time and resources, I would have taken a trace from the server.
Lastly, we did find that the server was sized properly and the administrator found that the server needed more RAM and CPU’s.
About the Author
You May Also Like