Measuring Performance


In this section we discuss how to measure the performance of your application. We describe the tools and techniques you can use, some metrics that relate to performance, and how to interpret testing results.

Tools such as Application Center Test (ACT, which ships as part of Visual Studio .NET Enterprise Edition) allow you to get some performance data on your applications by recording and running scripts that make requests to your Web site and record and collate performance information on the requests. Most of these kinds of tools allow you to specify a number of client machines from which requests will be made during the test; ACT also allows you to specify the number of threads on each client and the number of connections on each thread. ACT allows you to record scripts just by clicking through your Web application in Internet Explorer. If your application doesn t lend itself to being tested in this way, you may have to create the scripts by hand. This manual approach involves adding GET / POST entries to specific URLs with specific data. Most Web stress tools have similar facilities for custom scripts.

ACT, like most tools, allows you to specify a duration for the test and a warmup time. It s important to enter a reasonable warm-up time so that your application will be in its steady state when the main test is run. That is, any data that will generally be retrieved from the cache will already be cached, all DLLs that will generally be loaded during a request will already be loaded, all SRF files that will generally be parsed will be in the cache, and so forth. Using a reasonable warm-up period ensures that the performance data won t be impacted by start-up time costs. For the duration of the test, usually a short period of time is enough to get accurate performance data. A 10 “30 second warm-up time and 1 “5 minute duration should be adequate for the majority of applications. If your application needs to do more at start-up or takes a particularly long time to handle requests, you would need to adjust your settings accordingly . But for a typical ATL Server application (that is, SRF files and simple database requests), these settings should suffice.

Another setup issue has to do with keep-alive connections. Unfortunately, ACT doesn t allow you to easily set this option, but most commercial tools will allow you to specify connections should be kept alive between requests, thus eliminating the cost of reopening the connection on every request.

Once you ve run your test, the tool will report a summary regarding the total number of requests made and the number of success codes returned, failure codes returned, and so forth. The first thing to check is that the return codes reported are as expected ”that is, if you aren t expecting any failures, make sure there are no failures reported. ACT, like most tools, has a variety of metrics that are reported . What metrics are relevant depend on your application, but generally the most useful performance metrics are Requests Per Second, Average Response Time, Time To First Byte, and Time To Last Byte. Some other relevant metrics for diagnosing performance bottlenecks are Total Requests, Total Bytes Received, and Total Bytes Sent.

Requests Per Second is the most generally useful metric to measure the performance of your application because it tells you how much load it can handle. Average Response Time, Time To First Byte, and Time To Last Byte are useful metrics for testing the responsiveness of your Web site. Depending on what s most relevant to your Web application, you would weigh these performance metrics differently. If it s more important that your application be able to handle a very large user load, then Requests Per Second will be very useful, but if it s more important for your application to be snappy and responsive for the user, Time To First Byte and Time To Last Byte may be more relevant to you.

When you re diagnosing performance issues, Total Requests, Total Bytes Received, and Total Bytes Sent are useful metrics to help determine where your performance bottleneck is. Using the aforementioned metrics in combination with the duration of the test, you can determine the network usage in terms of megabits per second for your application and compare that against the capabilities of your network connection to determine if your application is network bound:

(((Total Bytes Received + Total Bytes Sent)*8)/1024)/(Duration in Seconds) = Megabits Per Second

You can also use the Win32 performance counters to determine network usage during the test. Though you ll almost never reach the maximum capabilities of your network and there are other considerations (such as network packet size , other network operations, and so on), this metric can help you narrow down your performance bottleneck when you use it in combination with other metrics, such as CPU usage on the Web application server and the database server. For a typical ATL Server application, if the CPU usage on the Web application and database servers isn t 100 percent, then your bottleneck may lie elsewhere, such as in the network. This isn t always the case, however, as you may be spending a lot of idle time in locks on the Web server if you ve written custom caches.

The Windows performance counters can be very helpful in narrowing down performance problems. You can use the counters to track issues such as excessive file I/O, memory leaks, page faults, and so forth, all of which can severely impact performance. The ATL Server framework also provides performance counters to track data within the framework itself. The ATL Server performance counters include information about requests per second, average response time, the number of active threads, and the number of requests waiting for an active thread, among other things.

Another consideration to keep in mind is the request size. Using too many query parameters, form variables , or cookies can result in the request size being larger than necessary. This is also true of the response size. Try to make the response as small as possible. Avoid sending too many cookies back to the user and try to minimize the page size as well. One good way to reduce the size of your pages is to eliminate unnecessary white space from your pages, as HTML will ignore most white space anyway.

A final consideration is client-side performance. From the end user s perspective, poor client-side performance can be just as much a problem as poor server-side performance. Coverage of efficient HTML design is outside the scope of this book, but some common problems include excessive script code, overly complicated tables, too many frames , too many images, or images that are too large.

One final tool that s helpful in performance tuning any application is a profiler. Many commercial profilers are available that can provide good data on your Web application hot spots. If you need to specify the process to which you have to attach, you ll need to attach to the process in which the ATL Server ISAPI DLL is running. If your application is running in-process, this will be inetinfo.exe on Windows 2000 and earlier, and w3wp.exe on Windows Server 2003. If your application is running out-of-process, this will one of the dllhost.exe processes on Windows 2000 (you can determine which dllhost.exe process has your DLL loaded by using tasklist m < isapidllname > ).




ATL Server. High Performance C++ on. NET
Observing the User Experience: A Practitioners Guide to User Research
ISBN: B006Z372QQ
EAN: 2147483647
Year: 2002
Pages: 181

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net