Application Profiling - A Microsoft Network Perspective

By Alexander Levin, Microsoft Information Technology Group—Network and Systems Analysis

Editor's Note This article is excerpted from "Optimizing Network Traffic," which is part of the Microsoft Press Notes From the Field series that outlines the best system management practices and procedures. For more information on this and other Microsoft Press books, go to https://www.microsoft.com/mspress/.

The study of applications as network components is relatively new among IT professionals, but it is rapidly increasing. One reason for this growth of interest is the significant increase of WAN usage, especially with browser-based applications. Connection to a WAN makes it easier to create large-scale networks, but to what avail if applications perform poorly over them? Another reason is money. Bandwidth can be expensive, and it is important to realize that more bandwidth is not always the only (or even the best) way to improve application performance. This realization, of course, is based on a growing understanding of how applications and networks cooperate and coexist—a profitable knowledge that impels a more systematic study of applications and how they work (or don't work) over networks.

So these ideas have been worked out relatively recently. Meanwhile, down in the trenches, users watch their applications limp along, grind down, or hang up, and their natural inclination is to blame the network, and by extension its architects, for what seems to be bad network design and worse performance. Of course more bandwidth will move things along at an acceptable rate. Anyone knows that. But suppose you spend a lot of dollars to add a lot of throughput only to find that application performance still is unacceptable. Now what?

On This Page

In Focus
What Exactly Is the Problem?
A More Detailed Itinerary
What About the App?
Information Delivery and Application Design
What To Do

In Focus

Enterprise

An inside view of some network analysis done by Microsoft's Information Technology Group.

Network

This discussion contains a collection of best practices and recommendations derived from studies of the performance of intranet applications put into production on Microsoft's corporate network.

Challenge

Build corporate intranet applications with efficient WAN performance in mind—a design concept that is not difficult to incorporate.

Solution

Improving the performance of a Web-based or Visual Basic application, especially over the wide area network.

What You'll Find In This Chapter

• Framework for understanding network application communication.

• What poor transaction performance over a network looks like.

• What network communication looks like for a well-designed application.

• Tips on how performance can be enhanced, and other implementation considerations.

What Exactly Is the Problem?

In this context, complaints about an application's performance are really complaints about the performance of a large system consisting of hardware (workstations and servers), software (applications), and internetworking infrastructure. Each component introduces a delay in the response after the user clicks a mouse button then sits back and waits for something to happen.

Performance is not simply a function of the application design, although that can be an important component. And it is not simply a function of network architecture, although it, too, is significant. As with most things, the answer is at once simpler and more complicated. Much of it has to do with the relationship between application and network designs, and some has to do with the simple physical limitations on moving things around.

The Round Trip

So while the user is thumb twiddling, the request initiated by the mouse-click is moving through multiple layers of the operating system doing lots of things. The instruction goes through the network card onto the wire, goes through the hubs, switches, and routers on the way to a destination that can be anywhere in the world. Eventually, the request arrives at that destination computer, which often puts it in the queue for service, processes it after some time, then sends it back across the network to the requestor. This is a simplified explanation of the request-response process but even so it takes you some time to read it: in real life time is likewise spent at every device along the way to the server and back.

To Speed Things Up

If this process simply takes too long, the first step is to upgrade the computer. Now the client's portion of a Visual Basic application (for example—if it is local on the computer) or Internet browser loads faster and the request to the server gets out of the client computer faster. But the target server is far away, somewhere on the WAN, across the country perhaps. A new machine won't speed up the transmission process, nor can you assume that assigning more bandwidth to the network will fix communication latencies. The response still takes a relatively long time.

The frustrated user's next request is to upgrade the network, but this is where jaws start to drop—and well they should because this can be an extremely costly proposition.

A More Detailed Itinerary

Let's follow the request again and see what can be sped up and what can't. After the user's request (a network packet) is sent onto the network it may pass through a shared Ethernet connection, where, if there is high network usage, it may have to wait until a wire is accessed. This is the first delay. The good news is that this is a network problem and networking people can remove or alleviate it by segmenting the network, reducing broadcast levels, removing "chatty" protocols, or introducing a switched environment and assigning each user a switched port.

Once it is on the Ethernet wire the packet can get moving again. If it has been sent out on a large enterprise network, it now has to cross several switches and routers (with possible media changes—between 1514-byte Ethernet packets and 4500-byte FDDI packets, for example) until it reaches the edge router, which connects the LAN to the WAN. Getting to the edge router of course takes time, and how much depends on device performance and network utilization on the wire, but normally this route is traveled quickly because LANs tend to have high bandwidth available.

That's good news, but in such an interconnected environment you can expect a downside even to good news and here it is: LAN speed is much higher than WAN speed, so the packet often is delivered quickly to a place where it has to wait. If the WAN link about to be entered is highly utilized there probably will be a queuing delay on the router. Right here, the five-lane freeway dumps its traffic into a one-lane residential road.

Still, corrective actions are possible. IT specialists can monitor the depth of the queue and the number of discards, and can make adjustments. When a router discards too many packets either it has insufficient performance for its position in the traffic flow or the WAN link on the other side is too slow and just cannot accommodate the required amount of data. These things can be fixed relatively easily, usually with money: installing a more powerful router or upgrading the link, and so on.

Sooner or later, the packet passes through the queue and is placed on the wire. The faster the circuit speed, the quicker the packet gets on the wire. For example, a T1 circuit (1.536 Mbps) takes about 7.8 ms to get a full-size Ethernet packet (1514 bytes) onto the wire. A 512-Kbps circuit, takes about 22.9 ms. (Other factors, such as TCP window size and circuit utilization, influence transmission performance, but they are not in the scope of this chapter.) The time it takes to get the packet onto the wire is significant, but bigger delays lie ahead. Specifically, if after all this travel the application is inefficiently designed, the process gets into double jeopardy, where the scores can really change.

At last, the bits are on the wire. They have to fly to the other end of the circuit. This they do at the speed of light, regardless of the speed of the circuit connecting the two end-points. No way to speed things up here, and anyone reading this who knows of one should please contact NASA.

While the packet flies along the wire, let's talk about application architecture.

What About the App?

A significant factor when you are assessing performance is how applications function in a distributed environment where a physical distance separates information requestor (client computer) and provider (server).

From this perspective, there are two types of applications: custom designs with client and server software portions (for example, Microsoft Visual Basic-type applications), and designs based on a standard Web browser (such as Microsoft Internet Explorer), residing on the client and having no additional specially designed software. Both types function the same way: the client portion of the application or browser has to be loaded and then has to access a remote server to get information.

In the simplest case of, say, a Visual Basic application, there are two computers in the communication path: the client and, say, a Microsoft SQL Server. The browser-based application has a more complex path. Its client computer communicates with the front-end (say a Microsoft Internet Information Server computer) which in turn communicates with the SQL server on the back-end.

Information Delivery and Application Design

The process by which instructions (the packets on the wire) are moved across the network and the information is delivered is (or should be) a crucial consideration in any application design. Although the process is hidden from the user, it is obvious to the network specialist. What the application developer has to consider is essentially a simple fact: information is not delivered in a continuous stream. (except for streaming applications). It is delivered in packets, controlled by the application and protocol logic, and the client and the server "discuss" this process.

In the case of a poorly written application, this "discussion" can be as diffuse as cocktail party chatter. In the figure below, each line from left to right or back represents a single packet being moved from source to destination. To move each packet over the WAN takes time: to move it from Boston, MA, to Redmond, WA, for instance, takes 45 ms; between Redmond, WA, and Sydney, Australia, takes 270 ms. Even the larger of these figures is a very small amount of time when you are talking about one request and one response, but it accrues into a some genuine and actual time when you perform enough trips between sites, and this accrual is what makes slow application performance. Figure 9.1 shows how.

Figure 9.1: Schematic of network communication for a poorly-designed application.

Notice how much time and bandwidth are wasted by the passing back and forth of pleasantries instead of information. On the other hand, a well-written application (Figure 9.2) handles the exchange as if it were delivering marching orders:

Figure 9.2: Schematic of network communication for a well-designed application

What To Do

Even a poorly written application won't frustrate users by performing slowly if it is run only on a LAN, especially if the network is fast and underutilized. On an extremely fast LAN, an application can be a model of inefficiency and still escape notice and the usual abusive comments. Put it out on the WAN however, and people will quickly spot it for the sloth that it is. When this happens, here are some things to examine in the application profile:

• HTTP protocol version. Older browsers are based on the HTTP 1.0, which is inefficient on a network because it unnecessarily opens and closes TCP connections, initiating additional round trips on the network.

• Persistent connection. Stay connected to the server during the transaction. Inefficient logic in the application can cause repeated connection.

• Smooth information delivery from the server. The requested material should be sent from the server as a single stream of packets. The client requests the information but should not control its delivery. Only TCP and window size should control the flow.

• Server location. In a large computer system round-trip time can be reduced by creating local servers or adding servers closer to the client (if possible).

• Local storage. For client-server applications (not browser-based ones) storing the client's portion on the client rather than downloading it from the server speeds things up.

• Cache screen designs. This applies to Visual Basic applications, which require that the server deliver screens. Inefficient applications bring the whole screen design down from the server with every query. Caching it reduces traffic.

• Remember distance. When the application is communicating over the WAN (not just the LAN) and the (IIS) server front-end and the (SQL) server back-end are far apart and the dialog between them is not optimized, performance can be severely degraded.

• Reduce exchanges. For non-multimedia applications, which have different requirements, network exchanges should be kept to a minimum. Putting more into one request avoids sending additional details later on. Use full-size packets.

Application redesign is expensive. The time to think about an application's WAN behavior is before coding. Either way, the characteristics below, which should be considered when creating efficient distributed applications, can also help explain poor performance in inefficient ones. Consider:

• Location. Where are the clients and servers with respect to each other? Is an application executing over the net frequently when it could be stored and run locally, with only results sent over the network?

• Mode. How is the application used? If it is for real-time (say for customer support) its response should be optimized. Other applications can afford to take longer. Every application should work efficiently, but not all need to be lightning bolts across the PC screen.

• Distribution. Sometimes it makes sense to distribute databases. A heavily used application can be helped by placing a lightweight database server on site to provide fast access and speed up response. This server can be synchronized with the main database

• Timing. Take some administrative steps to bring data closer to users by moving it over the WAN during off-hours (night is the obvious choice) when network usage is lower.