Conclusion

Network Latency

The simplest definition of network latency is the time it takes for a data packet to move across a network connection. The lower the latency between your Web application tiers, the faster the response times. Latency and bandwidth are two factors that determine the speed of a network connection. An easy way to determine the network latency between your client and a Web application is to use the pathping utility, or other utilities such as the Visual Trace Route feature provided in Application Expert. A PowerPoint presentation of Compuware’s Application Expert can be found on this book’s companion CD.

NOTE
The pathping utility is a command-line tool that combines features of the ping and tracert commands. To use, open a command prompt and type pathping servername . The output from the pathping command will show you the hops or network routers between the client you are using and the server you are pinging, along with the latency or round trip time for the particular hop.

Every local area network (LAN) and wide area network (WAN) connection is constrained by network latency. Factors that cause latency to increase are poor quality network devices, longer distances causing communication travel through more hops or network devices, and network congestion. For example, a typical 56-kbps local modem connection may have 200 milliseconds of latency, while a similar connection traveling a farther distance may pass through more network devices, which increases the latency to 500 milliseconds. In Table 5-1, we captured a trace with Network Monitor to measure the impact of network latency when requesting the 46-kilobyte home page of IBuySpy with our Microsoft Internet Explorer Web browser. The capture was imported into Application Expert’s Response Time Predictor, and we are able to extrapolate the response times for both a 200-millisecond and 500-millisecond latency 56-kbps connection. We’ll discuss this Application Expert feature and others in the “Using Compuware Application Expert” section later in this chapter.

The impact of the additional 300 milliseconds of latency for this particular page view and all associated elements is 2.5 seconds, not 300 milliseconds. The reason for this is latency affects every application round trip.

NOTE
One way to deal with the impact of latency is to locate your Web application closer geographically to your user base. This does not guarantee a better connection between your user base and Web application but will typically reduce the amount of latency.

Network Round Trips

A network round trip is a client-server request-response pair generated by an application. A request-response pair sent from a Web browser to a Web server and back is considered a single round trip. For example, when you type in a URL in your Web browser, such as http://www.microsoft.com, each image, style sheet, or other page element defined in the response to your request (from the Web server) is counted as a separate network round trip. Additional round trips are involved in the setup of each connection to the Web server in this example. Later in this chapter we will discuss how Application Expert can be used to quickly obtain the number of round trips your ASP pages are consuming. Combined with latency, round trips have a profound effect on application response time. Imagine that your IIS servers are located on both the US East and West Coasts. You are located in Mountain View California and viewing your IBuySpy Login ASPX page on the West Coast IIS server takes 4 seconds while viewing it from the East Coast IIS server takes 6.5 seconds. Further investigation shows the latency for your connection to the East Coast server is 500 milliseconds while that to the West Coast server is 200 milliseconds. Because every round trip is affected by network latency, the East Coast response time is longer by approximately 2 seconds.

For most application developers, network latency on the Internet is out of their control. This is why it is important to develop applications that use as few round trips as possible to keep response times quick even under high network latency conditions.

Reducing Network Round Trips

The most effective method for reducing round trips is to reduce the number of objects per page. Table 5-2 shows two home pages for major Internet search sites that many of you have probably used before. The first home page has fewer than six objects and loads very quickly. The second home page has approximately 15 objects and loads much more slowly. Notice the difference in the number of round trips that are generated when each of these home pages are loaded.

Search Site 1 used in Table 5-2 was able to limit the number of objects to six and has a less than 10-second response time on most 56-kbps connections. They limit the number of objects to six by creating one large graphic at the top of their home page, which consists of eight images. Considering each object requested will create a network round trip, they have saved seven round trips by merging their eight small graphics into a single request.

Data Transferred

Data transferred is the amount of data moved between a client Web browser and Web server and is often measured in kilobytes. The best approach for measuring data transferred is to break down the scenarios within your application by page views including their associated elements. For example, the IBuySpy home page transfers 46 kilobytes of data non-cached the first time you access it and 24 kilobytes of data cached ( subsequent requests with many objects loaded from your Web browser cache located in the temporary Internet folder). Based on our experience, the amount of data transferred for a page view and associated elements of 50 kilobytes or less will give an acceptable response time. This allows low speed Internet connections like 56-kbps modems the best chance of having fast response times. This chapter uses several terms to quantify data, such as kilobits per second and kilobytes of data transferred . Therefore to better illustrate how these metrics relate, Table 5-3 shows the conversion from bits to bytes, kilobits to kilobytes, and kilobytes to megabytes.

Reducing the Quantity of Data Transferred

There are several techniques for reducing the amount of data being transferred between Internet Explorer and the IIS tier . These methods include IIS compression, removing unnecessary characters and white space, reducing the number of objects on pages, and optimizing images.

HTTP Compression is a built-in feature of IIS and Internet Explorer. This tool works well for static content like HTM files, HTML files, CSS files, JS files, and uncompressed images. However, with dynamic content you may run into some problems, such as pages rendering incorrectly or becoming non-functional. There is also additional overhead associated with resources on your IIS server if you choose to use IIS compression. By default, HTTP Compression is disabled and can be enabled using the WWW Service Master Properties Services tab, shown in Figure 5-1.

Figure 5-1. Enabling IIS compression

Once HTTP Compression is enabled, you must specify the file types to be compressed by editing the metabase . The following steps show how to edit the metabase settings to compress static TXT, JS, CSS, DOC, and XLS files:

1. Enable HTTP Compression as shown in Figure 5-1.

2. Open a command prompt and navigate to the adminscripts folder.

3. Execute the following command: cscript.exe adsutil .vbs set W3Svc/Filters/Compression/GZIP/HcFileExtensions “txt” “js” “css” “doc” “xls”

4. Execute the following command: cscript.exe adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcFileExtensions “txt” “js” “css” “doc” “xls”

5. Execute the following command: iisreset.exe /restart

Another method to trim down the amount of data transferred between the browser and IIS tier is to package the data more tightly by removing all unnecessary characters and white space from your code. This is particularly useful around loops when a lot of data is returned to the client. Also, many developers put comments into their code, which adds additional characters and lines to the page, resulting in more data transferred.

NOTE
If you are very conscious about reducing your page size as much as possible, use short variable and filenames as well as a flat directory structure. This will slightly reduce the amount of data transferred because you are passing less text to the client.

Reducing the number of objects on your page will decrease the amount of data transferred. Many sites use images for bullets and text instead of using formatted text. By limiting the number of elements and using colored text and background colors to make sections of the page stand out, you can reduce the amount of data transferred and network round trips.

Images make a Web site or application more visually appealing but there is a significant performance cost associated with using them. Use Graphics Interchange Format (GIF) images whenever possible. Using optimized or compressed images will reduce the amount of data transferred and typically does not impact the clarity of your pictures much. Most high quality imaging software suites will include a tool to optimize and compress your image files. Reuse images for your company logo, navigational bars or other images that are used throughout your application. Make sure you use the exact same name and path or Internet Explorer will treat it as a new image. After the initial fulfillment of the request Internet Explorer will cache the images locally. Another option is to preload images using JavaScript. This will load the images in the background while the rest of the page loads. Subsequent requests for the cached image will appear more quickly to the end user because the images will be cached locally in Internet Explorer.

NOTE
Make sure you set the height and width attributes of each image. It will load faster because the Internet Explorer client does not have to determine the dimensions.

Processing Delay

When client requests spend unnecessary time on the middle or back-end tier of an application, it is considered a processing delay . This can be due to poorly written code that can take several seconds to process, or poor SQL tuning and improper indexing causing stored procedures and other SQL commands to consume valuable time. Processing delays directly impact response times. To get the most gain out of our tuning efforts, we typically focus on delays longer than 1 second. However, your application may have stricter or higher standards depending on a number of variables including type of application and size of your user base. For example, if your application is designed to render large reports to a small group of decision support analysts, response time may be expected to be slower. This is because larger reports may take longer to process on your database server, and given that your user base is small, budget constraints may limit the amount of time you can spend optimizing this application. However, if your user base is very large and consists of customers ordering your products, you will spend more time optimizing the application’s response time to ensure that no sales are lost because customers are frustrated about slow response times.

Reducing Processing Delays

The most common way to speed the response time of your application is to reduce application-processing delays. This is accomplished by speeding up slowly executing ASPX, Managed Code, and poor SQL code. More details are available in the IIS, Managed Code, and SQL sections of this book. As discussed earlier in the “Identifying Application Processing Delays” section, by using Network Monitor display data view or Application Expert bounce diagrams, you can identify whether or not your page view and associated elements have processing delays and which tier is causing it. Next , determine where in your application’s code the processing delay is happening. There are several methods for profiling and identifying the code causing processing delays:

• With .NET applications you can enable tracing on your ASPX pages. After you request an ASPX page with your browser, the statistics and timing will be located at the bottom of your page view. To enable tracing at the page level, add the ASPX page directive Trace=“True” , as shown in Figure 5-2.

  

  Figure 5-2. Enabling tracing on ASPX pages

• With standard ASP applications, you can use timers in your code to identify problems. Simply add timing variables throughout your script and write the values to a text file. This method of ASP profiling will allow you to narrow processing delays to a particular function or line of code. This book’s companion CD includes examples of the ASP timing code for VBScript and JScript, which are called ACETimer­VB.doc and ACETimerJS.doc. Many times these delays are related to a specific call to a custom component that is inefficient or a SQL command that is taking several hundred milliseconds or even several seconds to execute.

  NOTE
  A simple profiling approach is to insert response.end in your ASP page where you suspect the processing is occurring. When this ASP page is loaded, the script will exit when this command is executed, exposing your processing delay. If no delay occurred, move the response.end command farther down in your ASP page and load again. Eventually you will narrow down the portion of your script causing the processing delay.

• The easiest way to identify SQL bottlenecks and processing delays is to use SQL Profiler. Simply create a SQL Profiler trace file while you request your page view. Any delays caused by SQL commands or stored procedures will show up in the Duration field of the trace file in milliseconds. Once you have identified these poorly performing SQL commands or stored procedures, you can work on optimizing them. For more information on optimizing your SQL commands and stored procedures, see Chapter 8.

Response Times

In reference to performing an application network analysis, response time refers to how long it takes data to travel from the client’s initial request to the completion of the request. Improving performance of your application is synonymous with reducing the overall response time for each of your application’s page views including associated elements. Some factors that constrain response times are a high number of round trips, low bandwidth, end users with high latency connections, a large amount of data transferred, and processing delays on the IIS code, managed code, or SQL code. We describe the process of using Application Expert to quickly calculate response times later in this chapter.

Response time acceptability depends on a variety of factors including the type of application, the function of each requested page within the application, the bandwidth and latency of your Internet connection. For instance, a requested page that has no interaction with a back-end database (that is, a static page view) or has a small amount of content should load faster than requested pages that are heavy in content or constantly retrieve or update data from a database (that is, a dynamic page view) will be slower. Table 5-4 shows the response times we consider acceptable when performing an application network analysis. Low response times represent applications with small static page views or very light interaction with a database. High response times represent applications with large page views or heavy interaction with a database.

User Scenarios

User scenarios are a collection of page views, including their associated elements, that implement business or functional processes. For example, searching the IBuySpy site (discussed in Chapter 3) is a good example of a real-world user scenario. The search scenario consists of several steps, such as loading the home page, entering a search string, clicking the GO button, selecting a product from the search results and viewing the product detail page. This scenario consists of two page views. Instead of capturing the entire user scenario, we recommend you conduct this analysis by separating the scenario into distinct user actions, like clicking a button or link to submit a form that makes a request to the Web server. The reason we isolate the user scenarios into separate page views or user actions is to help identify the exact causes of slow response times.

Identify User Scenarios