Optimizing Dynamic Web Content for IIS

If you want to improve the performance of your Web site, your first impulse might be to buy more hardware. After all, you can add inexpensive hardware components to increase the amount of memory, disk speed, and processing power on your machine. But you can optimize the performance of Internet Information Server (IIS) without adding hardware. You can fine-tune your Web content to put less stress on your system. (For information about tuning IIS, see Ken Spencer, "Optimizing IIS for Peak Performance," May 1998.)

Your Web site's content can be static or dynamic. Static Web content places few demands on the Web server because such content consists of standard HTML code that requires no server-side or client-side programming or scripting. When a browser requests a static Web page, the Web server simply passes the page's content to the browser. In contrast, dynamic Web content can heavily tax a server because it might require substantial server-side programming or scripting. When a client's browser requests a Web page that includes dynamic content, the information the Web server delivers to the browser depends on the state of certain data on the Web server or the client.

For example, for a catalog, you can create a dynamic Web page that reads product information from a database and dynamically constructs HTML pages that contain the product information each customer requests. This configuration lets you build an online catalog that contains hundreds of products but uses much less code than a similar static HTML catalog. You create dynamic Web pages to run on an IIS server using three techniques: Common Gateway Interface (CGI), Internet Server API (ISAPI), and Active Server Pages (ASP).

CGI
CGI was the first solution for creating dynamic content on the Web. CGI lets you create an executable program or script that runs on your Web server and receives input from a user's browser through environment variables that the server sets for the browser, or through standard input that the server redirects to a communications pipe the server creates. The CGI program uses the input to perform functions such as querying a database. Then the CGI program writes the resulting dynamic HTML stream to standard output. The Web server redirects this output to a communications pipe it creates, then transfers the HTML output to the user's browser. Every time a user requests a CGI program, the Web server loads the program into memory and launches the program in a new process. CGI programs require a separate instance and process space for each browser request, so they consume large amounts of RAM.

You can develop CGI programs using C, C++, Perl, or other scripting languages. CGI development tools must be able to read environment variables and standard input and write to standard output. Listing 1 is a simple CGI program I developed in C. When a browser requests Listing 1's URL, the program writes an HTML response to the browser. For more information about CGI, check out http://hoohoo.ncsa.uiuc.edu/cgi.

ISAPIMicrosoft introduced ISAPI, which lets you create dynamic content using DLLs rather than executables, in IIS 1.0. After IIS loads an ISAPI DLL into the IIS process space, this one copy of the code services all browser requests for the ISAPI extension.

You implement ISAPI DLLs as extensions or filters. Like CGI, ISAPI extensions receive input from the user's browser, process that input, and send responses to the browser. Unlike CGI, ISAPI extensions perform these functions within the IIS process. To access data that the browser supplies and send responses to the browser, ISAPI extensions access the Extension Control Block, a memory structure IIS provides for communication between IIS and ISAPI extensions. This simple in-memory operation improves performance over CGI's piping of input and output between processes.

ISAPI filters implement event-driven preprocessing and postprocessing of browser requests. ISAPI filters are DLLs that exist in the IIS process space and receive specific tasks from IIS. When IIS starts, ISAPI filters register which part of server request processing they need to participate in. IIS invokes ISAPI filters when registered events occur. For example, an ISAPI filter might participate in performing authentication requests, preprocessing a header, or sending a response to the browser.

Listing 2 is an ISAPI extension that I wrote in C++. This ISAPI extension writes a message to the Extension Control Block, and IIS returns the message to the browser. For more information about ISAPI, see the IIS software de- velopment kit (SDK) at http://www .microsoft.com/msdn/library. You must be a member of the Microsoft Developer Network to access this site.

ASP
ASP premiered with IIS 3.0. ASP lets you embed server-side scripting within Web pages and interweave scripting and straight HTML without using sophisticated programs. The ASP engine runs as an ISAPI extension that processes requests for files with .asp extensions and connects the files' scripts to an ActiveX scripting engine for interpretation. After the scripting engine executes a script, IIS returns the resulting HTML page to the browser.

IIS comes with Visual Basic Script (VBScript) and JScript (Microsoft's implementation of JavaScript), and you can install other scripting engines, including Perl. Using ASP's built-in Server object, you can write script that instantiates other Active Server components, such as ActiveX Data Objects (ADOs), which provide objects for database access.

Because you include ASP scripts in the same page as static HTML content, ASP provides a simpler programming model than CGI or ISAPI for creating dynamic Web content. ASP's simplicity makes development of dynamic content available to a larger population of Web developers. If you are familiar with VB and HTML, you can easily develop ASP Web pages.

Listing 3 is a simple ASP page that uses ASP's built-in Response object to place a text string in the HTML stream that IIS sends to the user's browser. The <% %> symbols identify script that the ActiveX scripting engine needs to interpret. For more information about ASP, see the IIS SDK.

Check the Performance, Please
Which of IIS's three mechanisms for developing dynamic Web content is best? Many developers use ASP because it's powerful and easy to use. But that doesn't mean ASP offers the best performance.

To get a sense of the relative performance of the three types of dynamic Web content, I ran some simple tests using Microsoft's Web Capacity Analysis Tool (WCAT), which comes with Microsoft Windows NT Server 4.0 Resource Kit, Supplement Two. (For more information about WCAT, see T.J. Harty, "Testing Your Web Environment," December 1997.) My test environment consisted of three computers: My Web server was a Compaq Deskpro 6000 with a 200MHz Pentium Pro processor and 64MB of RAM running Microsoft Windows NT Server 4.0 with Windows NT 4.0 Option Pack (which includes IIS 4.0). The controller for my tests was an AT&T Globalyst 730 with a 100MHz Pentium processor and 48MB of RAM running NT Server 4.0. My client machine was a Compaq LTE 5400 with a 150MHz Pentium processor and 80MB of RAM running Windows 95.

I tested the responsiveness of five different Web implementations: static HTML, CGI, ISAPI, ASP with no script, and ASP with a small script. Each page responded to a simulated Web browser's request for its contents by providing the text string "Hello, I must be going!" I used the CGI, ISAPI, and ASP (with a small script) code that Listing 1, Listing 2, and Listing 3 show, respectively. I used the static HTML program that Listing 4, page 173, shows as a baseline for comparing the other implementations. The ASP page with no script was identical to Listing 4, except the file extension was .asp. Testing ASP pages with and without scripts let me differentiate between the overhead the ASP ISAPI extension places on a page and the overhead ASP code with script creates.

For each implementation, I used WCAT to repeatedly run a thread from the client machine to the Web server that simulated a browser's HTTP get requests for the implementation's URL. Each test lasted 3 minutes, and WCAT measured the number of times each implementation produced the "Hello, I must be going!" string per second. I repeated the battery five times for each implementation and averaged the results, which Graph 1 displays.

The ISAPI extension was the fastest, opening an average of 168.43 pages per second. The static HTML page was close behind, with an average of 159.35 pages per second. My ASP page without a script registered an average of 133.16 pages per second, and the simple script in my second ASP page reduced the page's responsiveness to an average of 124.91 pages per second. CGI opened only an average of 39.13 pages per second.

These simple tests demonstrate the relative performance of each type of dynamic Web content, but the data doesn't correspond to response times for most Web pages. Real Web pages access far more complex content, including databases, sophisticated algorithms, and legacy data. Adding complexity to any form of dynamic content lengthens a page's response time substantially.

Evaluate Your Content
CGI pages produce the slowest response times because of the overhead they require to create new processes and direct information through communication pipes. ISAPI extensions offer the fastest response times because you implement them as in-process DLLs. ASP pages are in the middle, primarily because of the runtime script interpretation they require to process pages.

If you're responsible for managing your Web site's performance, consider the way you produce dynamic content. Focus on the pages that get the most hits and show the most sluggish response. You can easily identify which pages get the most activity using a tool such as Microsoft's Usage Analyst, which is part of Microsoft Site Server, Standard Edition. If any of your busiest pages are dynamic and if those pages have slow response times, examine the dynamic content's implementation and consider rebuilding the page. For example, if your logon or search screen is currently an ASP program, you might replace it with a faster ISAPI extension.

However, if speed isn't a problem with a particular page, I recommend sticking with ASP. It's simple, and you needn't over-engineer your site's performance.