Capacity Planning

Web Application Performance

If Web applications are an important part of your site, the performance of those applications is critical in determining the site’s capacity. Testing is the only way to find out the capacity and performance of a Web application. The Web Capacity Analysis Tool (WCAT) and Web Application Stress Tool utilities included on the Microsoft® Windows® Server Resource Kit companion CD are useful testing tools. Before writing an application, however, it’s useful to have a sense of the performance capabilities of different Web application types. In IIS 5.0, Internet Server Application Programming Interface (ISAPI) applications running as in­process dynamic-link libraries (DLLs) generally offer the best performance. Next best are ASP pages, followed by Common Gateway Interface (CGI) applications.

For most applications, the recommendation is to use scripting in ASP pages to call server­side components. This strategy offers performance comparable to ISAPI performance, with the advantage of more rapid development time and easier maintenance. For more information about Web application development strategy, see Developing Web Applications in this book.

It would be helpful here to look at some comparative performance data. Tests compared uniprocessor and multiprocessor performance for several tasks that were designed to be as similar as possible. These tests also measured and compared the costs of ISAPI, CGI, and static content, and ASP. In the test, each program takes a URL passed in the query string, maps it to a physical file on the server, and sends back that file. (For static content the URL is passed directly to the server, which responds normally.)

The ISAPI version achieves most of its speed by having much less overhead (and functionality) than the others; it uses the ServerSupportFunction(HSE_REQ_TRANSMIT_FILE) function. Even though the CGI version is nearly a line-for-line copy of the ISAPI version, it is slower because a new process must be started each time the CGI program is executed. Static content is fastest of all because IIS 5.0 is highly optimized for transmitting static content. In-process ISAPI and ASP applications execute faster than (pooled) out-of-process applications. Note that the test programs, while equivalent, are idiomatic. That is, each uses the best and most natural choice of tools from its framework. The ISAPI uses TransmitFile, which is extremely fast but is not available to ASPs or CGIs.

The following code sample is the ASP version, stripped of error handling:

   <% @ EnableSessionState = false %>
   <%   ' Usage: http://server/test/sendfile.asp?test/sample/somefile.txt
      strPhysicalFilename = Server.MapPath(Request.QueryString)
      Set oFS = Server.CreateObject("Scripting.FileSystemObject")
      Set oFile = oFS.OpenTextFile(strPhysicalFilename)
      Response.ContentType = "text/plain"
      Response.Buffer = true   'Default in IIS 5.0, but not in IIS 4.0.
      Response.Write oFile.ReadAll
      oFile.Close
      Response.End
   %>

The entire Sendfile Test Suite is included on the Resource Kit companion CD, with instructions on setting up and running the tests.

The scripts and executables were tested with Beta 3 Release of IIS 5.0 and Microsoft® Windows® 2000 Server, using WCAT and the Web Application Stress Tool. The tests were run for 60 seconds, with 10 seconds of warm-up time and 10 seconds of cool-down time.

Table 4.3 shows the performance of the different application types, running on uniprocessor and multiprocessor kernels. Table 4.4 shows the hardware and software used for the tests.

The figures given in Table 4.3 are the actual numbers of pages per second that were served during testing, and in that narrow sense they are absolute. In several other senses, however, they are relative. First, the software being tested was not the final release version. Second, different computer types will, of course, provide different performance for the same test. Finally, the performance of different application types depends greatly on the application’s task. Because this particular task is a relatively light load, it maximizes the differences among the various methods. Heavier tasks result in performances differences that are smaller than those reflected in the table.

Table 4.3   Performance of IIS 5.0

Table 4.4   Setup for the Performance Test

Note   These tests were conducted with “out-of-the-box” computers and programs. No additional registry changes or performance enhancements were administered.

Multiprocessor Scaling

IIS scaling to multiple processors is improving, but when all processors in one computer must share the system bus and other resources, symmetric multiprocessor (SMP) scaling simply cannot map 1:1 with the number of processors. Multiple system buses can help with this issue; but for computers in which all processors share a single bus, a pair of two­processor machines can provide more throughput than a single four-processor machine, and may have a similar price tag.

© 1997-1999 Microsoft Corporation. All rights reserved.