Oct.
 2004

In the two previous installments of this 3-part series (see Newspapers & Technology, July and September, 2004), we introduced Microsoft Server 2003 and its accompanying Web server, IIS 6.0.

The app is much improved from what was originally shipped with Windows NT. Among the most significant: its process isolation mode feature, which has the potential to greatly enhance stability and availability of your Web services.

Even with a reliable and stable service, however, there are often many variables in an application that can be tweaked to provide even better performance depending on a particular installation.

The good news is that IIS 6.0 is much more “self-tuning” than earlier versions, so that even installations with fairly high traffic (especially with static pages) and on a modern-day server with plenty of RAM, stand a good chance of working just fine.

However, when we talk about running Web applications under a moderate to heavy load, performance tuning becomes increasingly important.

Taking a hit

In any Web application there are usually a few specific areas where performance takes a hit, and finding these areas and trying to rework or eliminate them is a big step. Sometimes a system that was designed for a certain level of traffic will spiral into unacceptable response times when traffic increases beyond a certain point. This is known as a scalability issue. The more complicated the Web application becomes, the more chances you’ll eventually encounter one of these bottlenecks.

Sometimes a bottleneck in one place will actually create one in another area. For example, if a database is taking too long to perform a commonly requested search, requests will have to build up in a queue somewhere. If that queue reaches its limit and “thread locks,” or crashes the entire application, the finger may be pointed at the database when in reality, the queue may be insufficiently sized if the base technology of the database can’t be changed in the short term.

Locating bottlenecks

The usual way to locate these bottlenecks is by using a series of performance monitors included in Server 2003. These monitors allow users to view the server load and response time under a variety of real-world or test conditions.

Response time represents the time (often an average) that elapses between the initial request for information and when that data is delivered (or not delivered, when the server can’t provide it before the timeout limit is reached).

When your server is processing a large number of requests (under load), it may take longer to complete than if the server were unloaded.

For user requests, this can result in increased response time for clients. If the server is under an excessive load, users may perceive the server as slow or unresponsive.

IIS’ ability to handle heavy loads and respond quickly to requests is primarily dependent on the response time and scalability of the Web apps it is running.

Factors such as network latency, that is, the time it takes for information to be transferred between computers in a network, and database processing also affect response time - but these factors may be out of your control.

Instead, you can improve response time by tuning up your Web apps and by using the IIS features designed to manage server resources. The result? Heavy loads won’t cause bottlenecks or overload the server’s World Wide Web publishing service component.

Numbers and real-world performance

I won’t take up space describing exactly how to enable the different features of performance monitoring, as that information is readily available through Microsoft. I will, however, touch on a few different characteristics of Active Server Pages that can be analyzed to show how the numbers relate to real-world performance.

*ASP, requests per second: This excludes all static page requests (.htm, .html, etc.) and will vary considerably depending on how much ASP code is being executed and Web server capacity. You know you may have a problem when Web traffic is high but the number of requests barely budges. When that happens, it’s likely that there is a bottleneck in the Web application, as the actual requests are never reaching the ASP dynamic link library, or .dll, in a timely manner.

*ASP, Requests Executing: This gives you an idea of how much work your server has to do to execute Web page requests. If, for example, pages are executing quickly and don’t require a lot of input/output horsepower, the requests executing number will likely be low. If the I/O required for a page request is high (for example, querying a database via ADO or loading a large text file), then the number is likely to be high. The requests will go as high as the value of “AspProcessorThreadMax” as set in the system metabase, multiplied by the number of processors, multiplied by the number of processes hosting ASP. If the value of “Requests Executing” is high, “Requests Queued” is large and yet the CPU utilization is low, the value for “AspProcessorThreadMax” may need to be increased in the metabase.

*ASP, Requests Queued: Ideally, this number would not stray far from zero since a queued request is one that is being delayed for some reason. The maximum number of requests queued is determined by the setting “AspRequestQueueMax.” If the limit is reached, a Web browser will display the error page “HTTP 500/Server Too Busy.” If you notice these numbers deviating a great deal, the applications involved probably need to be rewritten.

General tips

Microsoft provides some general tips in order to improve performance on ASP-based Web applications; I’ll list a few of the top ones:

-Whenever possible, use managed code (C# or Visual Basic .NET), ASP.NET, or ISAPI applications. C# and Visual Basic .NET applications run faster than ASP because the runtime environment executes compiled code.

-Avoid managed code to unmanaged code “hops” in your application if possible.

-Use static files wherever possible. Static files can be retained in memory cache and do not require large amounts of disk activity to process.

-Run IIS in worker process isolation mode, which can be configured to periodically restart worker processes assigned to a given application pool. Recycling worker processes minimizes some problems attributed to faulty Web applications.

-As a general rule, if an ASP script is more than 100 lines long (counting lines of code in files brought in using the #include directive), write a +COM component to provide the same function. If written efficiently and debugged properly, these components can be 20 to 30 times as fast as a script for the same dynamic page.

-Test applications before they go live on a site. If the production server is multiprocessor, make sure to test the application on a multiprocessor staging server. This way, problems specific to that situation can be identified.

I encourage users of ASP and Server 2003 to explore articles in Microsoft’s Knowledge Base (http://support.microsoft.com/default.aspx) about application and performance tuning. What I’ve written is a start, but no substitute for digging more deeply into the specific instances that will occur with your Server 2003/IIS 6.0 installation.

Full disclosure: Goodman owns shares of Microsoft stock, both individual shares as well as shares contained in several mutual funds. 

Hays Goodman is the webmaster for Newspapers & Technology and GMToday, a Milwaukee-area portal. He has been involved in professional Internet development for six years, and welcomes your comments, feedback and suggestions for future Tips & Tricks columns. Write to him at webmaster@conleynet.com and include your contact information.