Using Microsoft Network Monitor

Using Microsoft Network Monitor

Network Monitor is a software-based network sniffer that can be used to analyze and troubleshoot data transferred between nodes and devices on a network. This tool is designed for several types of Information Technology (IT) disciplines. Network administrators often use Network Monitor to capture and monitor overall network utilization. Network Engineers may use Network Monitor to assist in troubleshooting potential bottlenecks in network designs and architecture. Developers may use Network Monitor to troubleshoot their code. In an application network analysis, Network Monitor is primarily used to identify the amount of data transferred and count the number of round trips used in response time calculations per page view, including associated elements or user actions performed that generate activity to the Web server.

Network Monitor for Windows 2000 is available in two versions:

• Network Monitor 2 Lite is available with Windows 2000 Advanced Server and Data Center editions. This version can only sniff network traffic from the local Network Interface Card (NIC) to other nodes communicating with it.

• Network Monitor 2 Full is available with Microsoft System Management Server (SMS) 2. This version allows traffic to be captured for all traffic on a network from a single location that has the Network Monitor driver installed.

Network Monitor captures frames of network data to help you detect and analyze network problems. It aids in tracking down problems with network applications by capturing data transferred between application tiers, network round trips, network time, and processing delays.

MAC Address and IP Address Setup

In preparing for your network captures, you should document all node MAC addresses and IP addresses. To do this, open a command prompt and type ipconfig/all from each back-end server and client. The output from this command will show the IP address information, DNS servers, DNS suffix, physical or MAC address, and other valuable information. This will make it easier to set up your capture filter and isolate network traffic created by the application. Often you can use a host file entry to force nodes to communicate with the correct NIC and IP addresses you are capturing on. The hosts file is typically located in the C:\windows\system32\drivers\etc folder and does not have a file extension. To add or change entries you can open the hosts file with Microsoft Notepad and follow the examples provided within the file.

NOTE
If you are using a client or server that has more than one NIC, make sure you either disable the extra NIC or ensure all traffic communicates on the same NIC.

Configuring Network Monitor Settings

Network Monitor needs to be properly configured before capturing data from your user scenarios. There are three key settings the capture filter, capture buffer, and network that can be adjusted to make sure you are creating a correct and complete capture.

Capture filters allow you to narrow down your network captures to the tiers or nodes that are used by your application. This makes it easier to isolate data transferred and round trips without analyzing unnecessary network traffic in the trace file. Figure 5-3 shows a typical capture filter.

Figure 5-3. Network Monitor capture filter

The capture buffer is an important setting to adjust. By default the buffer is set to 1 megabyte. If a page is transferring a large amount of data you may exceed this 1 megabyte limit. Typically we adjust the capture buffer to 10 megabytes to accommodate any large captures. Figure 5-4 shows the Network Monitor Capture Buffer Settings dialog box.

Figure 5-4. Network Monitor Capture Buffer Settings dialog box

It s important to make sure you capture on the correct network. With clients and servers that have more than one NIC, you need to set which network you want to capture on. To verify you are capturing on the correct network, start a Network Monitor trace and ping the IP address or URL of the Web application you are testing. Next, stop your Network Monitor trace and verify you collected the ping traffic. If not, switch Network Monitor to capture a different network and repeat until you capture on the correct network. Figure 5-5 shows where you set Network Monitor to capture on the proper network.

Figure 5-5. The Network Monitor Select A Network dialog box

Environment Setup

The hardware used in an application network analysis includes the test client, and all of the back-end servers that make up the application (IIS Server, SQL Server, Application Server) and any other network devices used (switch, hub, router, bridge, load balancer, etc.). Applications that require high availability and scalability typically use more than one identical Web server to load balance traffic volume. If your application is load balanced, you should ensure that only a single node (front-end Web server) is enabled during an application network analysis. The purpose of this is to make sure you are capturing traffic on the correct Web server. There are numerous ways to use Network Monitor to capture traffic created by your application. Here are a few:

• Most applications are made up of servers connected by a network switch, because every port has dedicated bandwidth and performance is better. Network switches isolate traffic from each port, which makes it impossible for Network Monitor to see traffic from each application tier. However, through port spanning or port mirroring you can configure most network vendor switches to copy or mirror all traffic from each port you assign. Consult your network hardware vendor for instructions on configuring port spanning. By using the SMS version of Network Monitor and plugging the network monitor capture client into this port, you can see all the traffic from each of your application tiers. Figure 5-6 illustrates this model.

  

  Figure 5-6. Using port spanning on your switch

• If you do not have access to your switch configuration or if port spanning is not an option available with your network switch, another simple approach is to plug all back-end servers that make up your application into a hub. Hubs share bandwidth amongst all ports; therefore, the machine you use as your network monitor client will be able to capture traffic from all tiers. Figure 5-7 illustrates this model.

  

  Figure 5-7. Isolating your network with a hub

• The full version of Network Monitor allows you to install a Remote Network Monitor Driver on each tier of your application to capture traffic remotely. If you choose this method, install the Remote Network Monitor driver on each of your application tiers. From the Start menu, choose Control Panel, and then choose Add/Remove Programs. In the Add/Remove Programs dialog box, click Add New Program. Navigate to Windows Components, then choose Management and Monitor Tools, select Network Monitor Tools, and click OK. This method allows you to gather the captures from all remote agents to one client. The benefit of this approach is that it s quicker than performing separate captures to get the data from all of your Web applications tiers. However, the disadvantage is it takes longer to setup since you have to install an additional component on each server. Figure 5-8 illustrates this model.

  

  Figure 5-8. Using Network Monitor remote drivers

• The easiest method for capturing traffic is to use the Network Monitor 2 Lite version on the IIS tier as your capture client. The IIS tier is typically located between the Internet Explorer client and SQL tier. Therefore, when the network monitor client is located on your IIS server you will be able to see all the traffic coming to and from it. Figure 5-9 illustrates this model.

  

  Figure 5-9. Using the IIS tier as your Network Monitor client

Capturing Network Traffic

Now that Network Monitor is installed and configured correctly and your environment is set up, you are ready to begin capturing network traffic. We have discovered a few tricks that will assist you in gathering captures:

• Because we typically break user scenarios down into individual user actions, we recommend creating a separate capture for each page view. Using this method easily identifies how much data is being transferred for each page view including associated elements. If you are looking for scenarios that are expensive in terms of data transferred or round trips you can sum the individual page views.

• Perform your Network Monitor captures several times to verify their integrity. In approximately 90 percent of the network analyses we have performed, the network capture is accurate, however, unless you do your captures a few times to verify, you can t be sure. We re-run each capture at least three or four times until we get consistent and repeatable results. Each sample should be similar if not identical in terms of round trips and data transferred.

• Network Monitor allows you to save the captures files (CAP), which can be used for further analysis or importing into third-party tools such as Application Expert.

• Save your Network Monitor filters and address database (discussed above) in case you need to recapture. Saving your filters will save time reconfiguring Network Monitor. Figures 5-10 and 5-11 show the Save Capture Filter and Save Address As dialog boxes.

  

  Figure 5-10. The Network Monitor Save Capture Filter dialog box

  

  Figure 5-11. The Network Monitor Save Addresses As dialog box

• The goal of the capture is to record only pertinent application data transferred between nodes. To achieve this, start the Network Monitor capture, request a page by typing a URL in the address window of a browser, then stop the Network Monitor capture as soon as the page finishes loading. The page is considered finished when your Internet Explorer client displays Done in the lower left-hand corner of the status bar. This will allow you to avoid excess traffic transferred after the page view is loaded.

Network Monitor Capture Structure

A Network Monitor capture file consists of two views, the capture window and the display data view. As illustrated in Figure 5-12, the capture window calculates the amount of data transferred between nodes.

Figure 5-12. The Network Monitor capture window

The display data view contains nine columns and can contain many rows, depending on the amount of data collected. By default the trace file will show the MAC address of the NIC. To make the trace easier to read, edit the address to show the machine name or machine type. Figure 5-13 illustrates a raw capture from a client browser to an IIS server to a SQL server and back.

Figure 5-13. The Network Monitor display data view

All data in these views is important, however, the critical data to focus on identifies the amount of data transferred, number of round trips, and total time.

Using Compuware s Application Expert

Application Expert provides advanced response time prediction capabilities and granular application-level details for tuning distributed applications to ensure optimal network performance. Application Expert is used as a packet sniffer or for importing binary capture files obtained through Network Monitor. Application Expert also can be used as a fully functional packet sniffer. We find the following features of Application Expert to be particularly useful when performing a network analysis:

Conversation Map

Once a network capture has been imported into Application Expert, you can model the conversation between applications tiers. Figure 5-14 shows the conversation map of IBuySpy home page (no cache). This figure shows how quickly the conversation map is used to determine the amount of data transferred and number of round trips for a page view including its associated elements.

Figure 5-14. Application Expert conversation map

The conversation map provides a top-level view of the nodes (Client, IIS, and SQL) and conversations associated with hitting the home page. The conversation is defined as the data transferred or communication between the various nodes in your application. You can view the conversations by bytes or select your choice of display metric, such as payload bytes, frames, or application turns or round trips by right-clicking to open the Conversation Map context menu. Referring back to Figure 5-6, we see a total of 46 kilobytes of data being transferred between the IE client and IIS server and a total of 18 round trips.

Bounce Diagram

The bounce diagram is an excellent feature that gives you the packet level view of your application tiers and allows you to identify processing delays. Figure 5 15 shows the IBuySpy Default.aspx bounce diagram.

Figure 5-15. Application Expert bounce diagram

The bounce diagram is a packet flow timing diagram for client/server conversations on the network. This view shows individual frames between nodes in the sequence in which they occurred during the capture. In Figure 5-15, the IBuySpy login page shows a very small processing delay of approximately 170 milliseconds between the Internet client and Web server.

In the bounce diagram, each vertical line represents a node and the horizontal lines on the grid represent relative time increments in seconds. The time is relative to the start of the trace, which is designated 0.00. Within the diagram, the colored horizontal lines represent captured frames. The size of each frame is indicated by a color described in the legend at the bottom of the window: red for fewer than 100 bytes, yellow for up to 512 bytes, green for up to 1024 bytes, and blue for more than 1024 bytes.

Thread Analysis

It is helpful to look at the threads and thread timing using the thread analysis view in conjunction with the bounce diagram to identify which requests are causing processing delays. This combination view lets you focus thread-by-thread. The panes are dynamically linked, so an action in the upper pane affects the display and data in the lower pane to give you multiple views. For example, when you click a thread in the upper pane, the display in the lower pane changes to show the frames associated with the selected thread. If necessary, Application Expert automatically zooms into the bounce diagram for you. When you click a frame displayed in the bounce diagram, you get the detailed information on that thread. Figure 5-16 shows a thread analysis of the IBuySpy Default.aspx page. Using the thread analysis feature in Application Expert, you can quickly identify all 16 objects associated with this page view. Identifying this information from the raw Network Monitor capture or Application Expert packet trace view takes much longer.

Figure 5-16. Application Expert thread analysis

To analyze your capture in more detail, drill into the packet trace for a specific frame by selecting the Drill Into Packet Trace option in the context menu or, in a bounce diagram view, double-clicking a frame. This view is similar to the way Network Monitor displays the raw capture. The packet trace view lists all of the packets and provides important information about each one including the frame number, acknowledgement number, window size, and total bytes (data transferred) versus payload bytes (total bytes minus overhead of headers and acknowledgement frames). The bounce diagram view, thread analysis view, and conversation map are visual representations of the raw data provided in the packet trace view. Figure 5-17 displays a packet trace of the IBuySpy Default.aspx page.

Figure 5-17. Application Expert packet trace view

Response Time Predictor Tool

The Response Time Predictor allows you to predict the impact of bandwidth and latency for overall response time. This is very useful in determining response times of your Web pages in a pre-production test environment. Having this data you can identify and fix performance problems before your customers begin using your application. For instance, if you have several page views that do not meet your criteria for response time acceptability, you have a chance to optimize them before your customers begin using your Web application. The predicted response time depends on a number of factors, including the number of network round trips, amount of data transferred, and processing delays which are modeled using algorithms developed by Compuware. In the Response Time Predictor, you specify the bandwidth and the latency parameters to characterize the production network. The bandwidth and latency should be defined for the slowest link between the communicating end nodes. Figure 5 18 shows a Response Time Predictor model for IBuySpy Home page.

Figure 5-18. Application Expert Response Time Predictor

Interpreting Network Captures with Application Expert

In previous sections of this chapter we identified and defined key components that are used throughout the application network analysis. We introduced Network Monitor, the application used to capture the network traffic between application tiers. Next, we will provide our method for analyzing applications for network efficiency and identifying response time bottlenecks.

The capture file is in a format that can be viewed in Network Monitor or imported into Application Expert. The capture file is not easily interpretable and can be intimidating for novice users. By using Application Expert to interpret the capture, valuable time can be saved. To import your Network Monitor capture files into Application Expert, follow these steps:

1. Open Application Expert.

2. Create a new application.

3. Open Windows Explorer and browse to the location of your capture files.

4. Drag and drop your capture files onto your newly created application.

Calculating Data Transferred

After performing the network captures, we isolate traffic between application tiers. Calculating data transferred with Application Expert is accomplished using the conversation map. Figure 5-19 shows there are approximately 15 kilobytes of data transferred between the Internet Explorer client IIS server tier and 4 kilobytes of data transferred between the IIS server SQL server tier for the IBuySpy Checkout.aspx page view including their associated elements.

Figure 5-19. Calculating data transferred with Application Expert

Counting Network Round Trips

Counting the number of network round trips is accomplished using the Application Expert conversation map. Figure 5-20 shows there are five round trips between the Internet Explorer Client IIS server and 10 round trips between the IIS server SQL server for the IBuySpy Checkout.aspx page.

Figure 5-20. Counting round trips with Application Expert

Identifying Application Processing Delays

Processing delays on the IIS or SQL server tiers will critically impact end user response time performance. These delays are caused by several factors such as slowly executing scripts or components in your ASPX pages, SQL stored procedures requiring optimization, or improper SQL indexes that add seconds to your page load time. There are a number of tools and methods you can use to determine if your application has a processing delay. One such tool is SQL Profiler to monitor the SQL server tier, looking at the IIS logs time taken field to estimate IIS processing duration, or using the Application Expert bounce diagram feature to identify excessive time between network frames.

NOTE
For debugging and testing purposes we recommend enabling logging within IIS and using the W3C Extended Log file format. This includes enabling all of the extended properties, such as time taken, bytes sent, and bytes received. For more information relating to the W3C Log file format, see Chapter 6.

If you find delays of more than a second between frames, this should be flagged and investigated for optimization. If you reduce this delay by making code changes, the overall response time for that particular page view will be reduced by the same amount. Figure 5-21 shows a 1.3-second processing delay on the IIS server tier for the IBuySpy update cart page.

Figure 5-21. Processing delay shown in Application Expert

Predicting Response Times

The Application Expert Response Time Predictor allows us to model response times using the quantity of data transferred, round trips, and processing delays in our network capture. These models show the response time predictions for different line speeds and network latencies, allowing you to discover if your application will perform as you expect before you roll it out to your customers.

NOTE
An alternate method for predicting response times at various connections speeds and latency is to use a hardware-based WAN simulator. Hardware WAN simulators are located between your Web application tiers and suppress the network signal to the programmed specification. For example, you can place the simulator between your test client and Web server tier and program it to reduce your connection to 56 kbps and 500 milliseconds of latency.

We typically use a mix of slow modem connections, high-speed broadband connections (DSL or cable modems), and typical office connections like T1, and LAN connections. For each of these connections you can do a best case and worst case latency. Keep in mind, the bandwidth and latency metrics used in these models are not set in stone. From our experience we use the following connection speeds and latency to simulate users:

• 56-kbps modem connections have a 200-millisecond latency best case and a 500-millisecond latency in poor conditions.

• 256-kbps DSL and cable modems have a 50-millisecond latency best case and 200-milliseconds in poor conditions.

• T1 (1.54-mbps) connections have a 50-millisecond latency best case and 100-milliseconds in poor conditions.

• LAN connections represent a 10- or 100-mbps connection, depending on your network infrastructure. Commonly you will have a 10-millisecond latency or less and 50-milliseconds in poor conditions.

As shown in Figure 5-18, the Application Expert Response Time Predictor allows you to change the line speed and latency for each of your applications tiers. The response time formula utilizes connection speeds, data transferred, round trips, latency, and processing delays. Table 5-5 demonstrates a typical response time model for the IBuySpy home page (no cache page) using our model with varying connection speeds and latency metrics.

Table 5-5. Modeling Response Times

Line Speed	56 kbps Modem	256 kbps DSL	1.54 mbps T1	10 mbps LAN
Latency	200 500 ms	50 200 ms	50 100ms	10 50ms
Response Time	6 9 seconds	2 3 seconds	1 1.5 seconds	.5 1second