1. Tracing your Application
Before NetworkSmart can troubleshoot your application's performance, it requires a network capture or "sniff" to analyze. If you are trying to troubleshoot a production problem, your network team may already have application captures available for you to analyze. If you have never captured network traffic before, you can easily begin by downloading one of the following network sniffers that are supported by NetworkSmart:
- Microsoft Network Monitor aka. Netmon (free network monitoring utility)
- Wireshark (open source competitor to Netmon)
Please review the Related Articles at the bottom of this page for more details regarding the download and installation of these free network sniffers. NetworkSmart also includes sample performance data so that you immediately see the features of NetworkSmart without having to capture traffic.
2. Understanding Application Topology
To correctly analyze the performance of your application and pinpoint a problem, it is important to properly capture the application traffic.
Web Application Example
For example, let's say we have a web application that talks to a database. If we only capture the traffic between the client and the web server, in NetworkSmart we may see that the login page took 7 seconds to load and that 6.8 seconds of that load time was due to server processing. However, even though this correct, the login page may not be the final culprit to this problem. Suppose that the login page makes 3 calls to a database server. In our example, if we captured traffic from the client to the web server and also from the web server to the database server, in NetworkSmart we may see that 1 of the 3 database calls took 6 seconds while the other 2 database calls took .5 seconds combined. We now clearly know that the 6 second database call is where the overall performance problem is with our web applicaiton.
When capturing your application traffic, make sure that you are properly capturing the complete topology of your application.
Things to Avoid when Capturing Traffic
Below are some common pitfalls to avoid when capturing network traffic:
- Capturing All Traffic instead of Filtering IP Addresses
Simply turning on your capture tool and recording all traffic on the network is easy enough; however, it makes it more difficult in the end to make sense of the data you are seeing. Too much of the data is unrelated to your application problems. Understand which machines are part of your application topology and configure the monitor to sniff only the traffic generated by those machines.
- Capturing multiple transactions from multiple clients
Another common pitfall is to capture multiple clients connecting to a server to perform the same transactions. Unless you are troubleshooting your application in production, issolate your problem by using only one single client machine to generate the transactions.
- Capturing longer than you need to
If your goal is to test the login page of your application, the only execute and capture the transaction you want to analyze. Do not capture other pages or transactions such as search or save. If the transaction takes 30 seconds to complete, then your capture should start before the transaction is executed and end after the transaction is completed. Do not turn on your sniffer for minutes or hours and record needless application traffic and transactions. Only record the transaction that you want to analyze.
- Filtering for specific ports or protocols
There are times when filtering for specific ports or protocols are good (such as when you want to specifically only look at your database calls). However, in general it is good to analyze all the traffic that is sent between two machines in your application. This allows you to understand if your application is making needless calls to the Active Directory or if it is calling out on a port you were unaware of. Simply filtering your application traffic by a specific port or protocol (ex. HTTP:80) may not show the real cause of your application's problem.
3. Defining Test Cases
The final step is to determine which part of the application you want to do performance testing on. You can simply make a list of functions that you would like to monitor. For example, this may be your top 10 most viewed web pages or it could be application functions such as database login, product search or shopping cart checkout. Similar to functional testing, you should know what you want to test before you begin the actual capturing of traffic.
List out on a sheet of paper the functions that you would like to perform using NetworkSmart.
• Add items to Shopping Cart
• Bring up the personalize logon page
• Upload a 20K image to the “My Photos” folder on the web
4. Begin Capturing
Now you have determined what you want to capture, you are ready to begin. Make sure to capture your transaction 2 or 3 times in order to allow for anomolies. For example, your network may have had a hiccup during a transaction and thus it took 5 seconds to complete. However, every time you run that same transaction earlier and later it only takes 1 second. You can no longer get it to take 5 seconds. If you were projecting response times, you would already be off base because your transaction on average did not take 5 seconds to run. By capturing the same transaction multiple times, you will be able to throw out any anomolies and you will have a consistent capture file with reliable data.
Once you have successfully generated a capture file, open the capture file within NetworkSmart and begin analyzing the results!
