An important feature of NetworkSmart is its ability to accurately predict application response time for any bandwidth and latency. This feature allows application teams to quickly identify and understand performance issues that could appear for certain customers once the application is deployed. NetworkSmart does not require any modifications in hardware or network bandwidth in order to simulate customer response times. Simply run your application in your current environment and NetworkSmart will effectively predict how the application will run in other environments.
Step By Step Instructions
Determine what to test in your application: The most important factor when predicting application response time is making sure you have a controlled transaction for testing. Determine what part of your application your want to test; such as logging in, searching, saving data, etc. The goal is to isolate transactions (or parts or functions of your application) that you can then determine response time for as well as drill into the performance data.
Important Tip: Having too many functions combined into a single transaction will make it difficult to actually determine what is going on. For example, if my test transaction consisted of logging into a database and then searching for a product and then saving the search results, I essentially have 3 functions compiled into one transaction. NetworkSmart will only measure these 3 functions as 1 transaction. Thus, if the database login took 2 seconds, the search took 7 seconds and the saving results took 1 second, NetworkSmart would show this transaction as 10 seconds. But it will be more difficult for the performance engineer to realize that the search part of the transaction was 70% of the total transaction time. Breaking your transactions down into single functions will allow you look at each part of the process separately (login, search, save) so that you will clearly understand which transaction is taking the longest. So in this example, it is smarter to have 3 individual transactions instead of 1 combined transaction. Doing this will allow you to better control the data that your are attempting to predict response time for.
Record each Transaction Multiple Times: Now that you know what you want to test in your application, the next part will be to use a network sniffer of your choice (either Microsoft Network Monitor or the open source sniffer WireShark). It is smart to configure the sniffer to filter for specific segments (ex. computer 1 to server 1) before monitoring the transaction. This will cut down on unrelated "noise" data when you are analyzing the transactions in NetworkSmart.
Once your sniffer is configured and ready to go, start the sniffer and execute the transaction and then stop the sniffer and save the capture file. Do this process at least three times for each transaction. By capturing the transaction 3 separate times, you are essentially removing possible anomalies in the sniff. For example if 2 of the sniffs took 4 seconds and the remaining sniff took 9 seconds, you will be able to assume that the last sniff may have resulted in a network hiccup, etc. Having 2 transactions with approximately the same sniff times will ensure that you properly captured the transaction.
Important Tip: When running the sniffer, make sure you are NOT recording secondary traffic during the execution of the test transaction. For example, maybe you are testing a web application. Your application thus uses HTTP as the protocol. However, on your test client, you may have file explorer open and connected to the server resulting in non-related SMB traffic getting recorded on your sniff. This will in turn negatively affect the results of your capture for the transaction. Either make sure that you have NO other process running across the segments that you are wanting to sniff (so they do not get recorded during the test transaction) or configure your sniffer to only sniff for a particular protocol in order to ensure that you have removed unwanted noise / erroneous traffic from your sniff.
Open Captures using NetworkSmart: Now that you have at least 2 similar sniffs for each transaction, select 1 and open it with NetworkSmart. When NetworkSmart has completed analyzing the data, the capture will be displayed in the navigation tree of NetworkSmart.
View Response Times: Select the capture from the navigation tree and click on the Predict tab. Response times for your capture will then appear.
Review NetworkSmart Performance Data: Displayed on the left side of the Predict window are NetworkSmart performance metrics. These metrics give you an overview of your transaction. In NetworkSmart, click on a metric to see an expanded description of the metric.
Important Tip: Review these metrics to see if your transaction contains any errors. If it does, click on the Dashboard tab or the Application Error Report to review these errors more in detail. For web applications, review the Application Objects section of the NetworkSmart Performance Data section to see if objects were sent across the network or if they were pulled from a local cache. You will most likely have incorrect response time predictions if you tested response times on cached objects; and in reality the true customer response times will be based on downloading application objects across the network instead of pulling them from cache.
Review Connection Information: In the Performance Data panel is a Connection Information section showing Bandwidth and Latency. These metrics are meant to represent the network environment that the transaction was captured on. By default, NetworkSmart predicts application response time based on traffic captured across a 100MB line with 5 ms latency. Change these settings to reflect what type of network wire the transaction was captured over (ex. 10 MB line, 54 MB wireless, etc.).
Predict Response Time Projections: The chart and the data grid below the chart show the response time predictions for your application transaction on the selected application segment. Current Speed represents the actual time that it took to sniff the transaction. This is your base response time that all other response times are projected from. The bars in the chart are broken down into 3 segments:
Server Processing: This part of the response time reflects the % of time required for the server to process the transaction (aka "think" time). The think time will be the same for all bandwidth scenarios as it is server related.
Bandwidth Processing: This part of the response time reflects the % of time required to deliver the data of the transaction across the network in a perfect world. Bandwidth processing is directly related to how much data can pass through the pipe. Increasing the size of pipe directly lowers the amount of bandwidth processing time.
Round Trip Delay: The final part of the response time equation is Round Trip Delay. This part represents how well your application is put together (ie. how many round trips, the efficiency in packaging your application and delivering it over the network, etc.). If your application is written with a lot of chatter or inefficiencies, it is possible to see this portion of the response time greatly increase as you predict over smaller bandwidth or higher latency scenarios.
Customize Predict Scenarios: Documentation incomplete…
Common Questions
Q. How Can I Lower my Response Times?
A. The first step to answering that question is to quickly look at what the largest colors of the Predict Graph are.
Yellow (Server Side): If most of the bar is "yellow" then your application is spending too much time processing on the server. Some examples of long server side processing problems are database calls on the server is not returning quickly enough, web servers responding slowly to specific requests, look-ups to other servers that require the application to be suspended until the look-up is complete, etc.
