The Myth of IIS Downtime

Many people who run small and large IIS Web farms believe that IIS is an unstable platform. They're annoyed because they need to restart their IIS server every hour, every 4 hours, or every 24 hours, so they naturally blame the software. In reality, however, IIS is an extremely stable platform that doesn't leak memory, crash unexpectedly, or require frequent reboots to remain stable. The real culprits of IIS downtime are probably your custom static files, Common Gateway Interface (CGI) applications, Internet Server API (ISAPI) extensions, ISAPI filters, Active Server Pages (.asp) files, and COM objects, which can cause IIS to crash if they run inside the same process space. To stabilize your IIS server, you need to take a look at IIS code paths and learn how the code in the above-mentioned file types affects the OS memory and threading.

Code Paths
To understand the causes of stability problems, you need to understand the different code paths that requests can take. Essentially, IIS handles five file types: static files, CGI applications, ISAPI extensions, ISAPI filters, and .asp files.

Static files. Static files are files (e.g., plain .html files, images) that don't need to be executed. They are the easiest of all the files for the Web server to deliver because the server needs only to read the file from disk and use the HTTP protocol to stream the file. If you have only static files on your Web server and a lot of traffic, the server could run for months and perhaps years without experiencing an IIS-related failure. However, you're probably using your server for more than just static files, so you can only imagine such a perfect uptime scenario.

CGI applications. Developers typically write CGI applications in C or C++ and deploy them on the server as executable files. Of the five file types, CGI applications are the least stable because they're typically programmed poorly. Developers who use CGI applications typically don't understand IIS and ignore the advantages of ISAPI applications and built-in scripting languages.

ISAPI extensions. ISAPI extensions are .dll files that expose APIs that IIS calls. You can map these DLLs to a file extension or call them directly. An example of an ISAPI extension is Macromedia's ColdFusion. ISAPI extensions are only as stable as their programmers design them to be. Before you deploy ISAPI extensions, you need to perform extensive testing, including stress testing, to ensure the stability of the ISAPI extensions. ISAPI extensions running in process will crash your IIS server if they overrun the stack or overrun their buffers, or if they divide by zero or perform other types of exceptions. Because of the necessary testing involved, programming a 100-percent stable ISAPI extension is extremely difficult.

ISAPI filters. ISAPI filters, which are different from ISAPI extensions, are DLLs that examine all requests entering the Web server. For example, ISAPI filters in IIS handle the Secure Sockets Layer (SSL) authentication protocol and compression. However, third-party ISAPI filters have the power to modify any of the IIS code paths and cause crashing problems.

.Asp files. Although you might think .asp is just another ISAPI extension, .asp files use a different code path in IIS. The asp.dll and the code in IIS are quite stable. An .asp file with simple ASP code or no ASP code will run without failure for months. However, bad code or—more likely—poorly written COM objects can cause .asp files to crash your server. If you aren't running any CGI applications, ISAPI extensions, or ISAPI filters—but you are running ASP with COM objects—then COM objects are most likely crashing your server.

Divide and Conquer
To track down a stability problem for a given file type, you must examine and test the Web server to categorize the problem into one of six areas:

• Thread locking—the server can't handle many requests simultaneously.
• High thread count—the CPU reaches 100 percent usage, but the server isn't doing any work.
• Memory leak—the Web server is slowly leaking memory. When the available memory diminishes to a certain point, the machine crashes.
• Runaway thread—the Web server CPU reaches 100 percent usage and never returns to normal.
• Bad request—a request (e.g., URL, query string, host, language, browser combination) is causing the server to crash.
• Miscellaneous—other types of stability problems that exist outside the scope of this article.

To determine the problem, you can use Performance Monitor to view the %Processor Time (under Processor), Get Requests/sec (under Web Service), Context Switches/sec (under Thread), and Available Bytes (under Memory) counters. In the event of a server crash, keep an eye out for the following determinants, which can point you toward the type of problem your IIS server is experiencing.

• If your %Processor Time counter is at 100 percent, you have a runaway thread or high thread count. If the value is low (e.g., less than 40 percent) and your Get Requests/sec counter also shows a low value (e.g., less than 10), you have a thread-locking problem.
• If your Context Switches/sec counter value averages less than 10,000 and the %Processor Time counter is at 100 percent, you have a runaway thread. If the Context Switches/sec counter value averages more than 10,000, you have a high thread count.
• If your Available Bytes counter shows a value that's slowly diminishing toward zero, you have a memory leak.
• To determine whether you have a bad-request problem, you need to first determine that you have none of the above-mentioned problems.

Thread Locking
Your machine probably has a thread-locking problem if the machine is handling only a few requests per second (e.g., one or two for every processor), the machine's CPU isn't working hard, and the pages are returning slowly. The primary reason for a thread-locking problem is that ASP has called a single-threaded COM object. Developers can choose to make COM objects multithreaded or single-threaded. Only multithreaded objects should be called from ASP because single-threaded objects keep threads and users waiting and can tie up your machine. This problem is common with Visual Basic (VB) COM objects, which tend to be single-threaded. VB components can also tie up your machine in other ways—for example, if they aren't compiled for unattended execution and if they're retained in memory. Microsoft offers the vbchkw2k.exe tool, which scans the DLLHost processes for incorrectly compiled VB components.

   Previous  [1]  2  Next