[This is preliminary documentation and subject to change]

Monitoring Your Web Applications

Web applications are essential to ecommerce. Customers browse products and make purchases with the help of Web applications. If a Web application is slow or not performing properly, the performance of your whole site can be affected. Poorly-designed Web applications can be the single greatest reason why customers do not complete purchases or decide not to revisit your site. This topic describes how to monitor and tune applications for improved performance.

note Note    Upgrading a poorly written application to one that is well designed and has been thoroughly tested can improve performance dramatically. Keep in mind, however, that your Web applications may be affected by back-end latencies (for example, legacy systems) and remote data sources. If developers design applications to get data from another Web site or server, and that Web site or server experiences problems, the problems will cause bottlenecks on your server.

Monitor the following performance counters to determine if your Web applications are creating a bottleneck on your server:

 

CountersDescription
Active Server Pages\ Requests/Sec

Active Server Pages\ Requests Executing

Active Server Pages\ Request Wait Time

Active Server Pages\ Request Execution Time

 Active Server Pages\ Requests Queued

If you are running ASP applications on your server, these counters can provide you with a picture of how well the applications are performing. Active Server Pages\ Requests/Sec does not include requests for static files or other dynamic content and will fluctuate considerably based on the complexity of the ASP pages and the capacity of your Web server. If this counter is low during spikes in traffic on your server, your applications may be causing a bottleneck. Requests Executing indicates the number of requests currently executing (i.e., number of active worker threads). Request Wait Time indicates the number of milliseconds the most recent request was waiting in the queue. Request Execution Time indicates how many milliseconds the most recent request took to execute. Ideally, Requests Queued and Request Wait time should remain close to zero, but they will go up and down under varying loads. The maximum number for Requests Queued is determined by the metabase setting for AspRequestQueueMax. If the limit is reached, client browsers will display "HTTP 500/ Server Too Busy." If these numbers deviate a great deal from their expected range, your ASP applications will likely need to be rewritten to improve performance. Request Execution Time can be somewhat misleading because it is not an average. For example, if you regularly receive 30 requests for a page that executes in 10 milliseconds (ms) to every one request for a 500ms page, the counter is likely to indicate 10ms, although the average execution time is over 25ms. It is hard to give an ideal value for Requests Executing. If pages execute quickly and don't wait for I/O (loading a file or making a database query), this number is likely to be low (little more than the number of processors when the machine is busy). If pages must wait for I/O, the number of pages executing is likely to be higher (anything up to AspProcessorThreadMax multiplied by the number of processors multiplied by the number of processes hosting ASP). If Requests Executing is high, Requests Queued is large, and the CPU utilization is low, you may need to increase AspProcessorThreadMax. When enabled, thread gating seeks to optimize Requests Executing. The user's response time is proportional to Request Wait Time plus Request Execution Time plus network latency. 

These counters are the sum of the ASP performance counters for each process hosting ASP, and there is no way to break them down by process.

Web Service\ CGI Requests/sec 

Web Service\ ISAPI Extension Requests/Sec

Reports the rates at which your server is processing CGI and ISAPI application requests. If these values drop while under increasing loads, you may need to redesign the applications.

note Note    ASP is an ISAPI extension and is included by the second counter.

Web Service\ Get Requests/sec 

Web Service\ Post Requests/Sec

Reflects the rate at which these two common HTTP request types are being made to your server. POST requests are generally used for forms and are sent to ISAPIs (including ASP) or CGIs. GET requests account for almost all other requests from browsers and include requests for static files, requests for ASPs and other ISAPIs, and CGI requests.

Tuning Your Web Applications

This section does not attempt to discuss the intricacies of tuning your Web applications; this section does provide recommendations for improving application performance. Consider the following while planning and testing your Web applications:

  1. ISAPI applications run faster than Active Server Pages (ASP) applications, though there is much less developer overhead for ASP. Both of these types of applications run faster than equivalent CGI applications.
  2. Use static files wherever possible. Static files do not require large amounts of memory or disk activity to process.
  3. Design your site so applications push the processing load onto the client. Client-side processing helps to avoid network latencies, conserves server-side resources, and allows changes to appear instantaneously to the user. A common example is adding client-side code to validate that forms have been filled out with good data, such as checking that e-mail addresses are well formed or credit card numbers have a correct checksum.
  4. Make sure that debugging for ASP is turned off on your production servers. If debugging is enabled, you will need to set the AppAllowDebugging metabase property to FALSE.
  5. Set Expires headers for all images and for HTML wherever possible so these types of files will be stored in the client's cache. 
  6. Do not store Apartment-threaded components in ASP Application and Session state, which includes all Microsoft Visual Basic® components; Java and most C++ objects are not included.
  7. Use Secure Sockets Layer (SSL) only when necessary. Using the HTTPS protocol is much more expensive than standard HTTP. Be sure that the information being sent, such as credit card numbers or medical information, is sensitive enough to warrant the added performance expense. For more information about security tuning issues, see the Security section in Measuring Hardware Performance.
  8. Isolate processes and applications. IIS 6.0 Web applications run in the out-of-process pool (medium protection) by default. It is safer to take the performance impact of process isolation than to risk server downtime and data loss that can be caused by a low-isolation application crashing the Inetinfo process. 
  9. To enhance database-driven performance in a production environment, use Microsoft SQL Server 2000. IIS and SQL Server perform best with plenty of memory, so store the database on a separate server from the Web service. In this situation, communication across computer boundaries is frequently faster than communication on a single computer. Performance degradation due to a lack of memory and insufficient cycles often occurs when both SQL Server and IIS reside on the same server. Also, be sure to create and maintain good indexes. This will minimize I/O on your database queries. Also, take advantage of stored procedures. Stored procedures take much less time to execute and are easier to write than an ASP script designed to do the same task.
  10. As a general rule, if you have an ASP script that is more than 100 lines long (counting lines of code in files brought in using the #include directive), consider creating a COM+ component to provide the same function. If written efficiently and debugged properly, COM+ components can offer twenty to thirty times the processing speed of a script for the same dynamic page. The easiest way to measure the size of an ASP script with #includes is to change the file extension of the page from .asp to .stm and open the .stm file with your browser. Use your browser's View Source command to display the .asp file and lines of code from the included files.
  11. Test applications before they go live on your site. If your production Web server is a multiprocessor system, be sure to stress test on a multiprocessor system so you can identify multiprocessor scaling problems and race conditions in your script and components. The Web Application Stress Tool (WAST)is a good tool for this kind of stress testing. See Tools Used to Monitor Performance for more information.

Related Topics

© 1997-2001 Microsoft Corporation. All rights reserved.