A Typical Web Request from a Performance Perspective

In this section you ll look at a typical ATL Server Web request from a performance perspective. You ll learn where your time will usually be spent in a typical ATL Server Web request.

When a Web request first reaches the server, it must first go through the infrastructure of IIS before it reaches ATL Server (see Figure 20-1). Additionally, it must go through IIS when it s writing output, completing the request, and making queries for request information to IIS (HTTP headers and so forth). The exact overhead of the time spent in IIS depends on the type of request, the size of the request, the number of queries made to IIS about request information, and the size of the response. However, for a typical Web request, the overhead is between 5 percent and 10 percent of the execution time of the Web request. In general, most of the time is spent cracking the request parameters and headers, determining the ISAPI extension to which it will dispatch the request, and creating the ISAPI control structures to pass to the ISAPI extension.

Figure 20-1. A typical Web application request involving databases

After IIS has done its initial processing of the request, it dispatches it to the ATL Server ISAPI DLL. Once it reaches the ATL Server ISAPI DLL, the request goes through several stages of processing. When the ATL Server ISAPI extension receives the request, it first creates an ATL Server “specific information structure for the request and puts it in its own thread pool, thus freeing IIS to continue handling other requests on the IIS thread pool. ATL Server then has slightly different behavior depending on whether it s processing the request as an SRF request or as a DLL request (see Chapter 5 for more details).

From a performance perspective, there s no significant difference at the ISAPI level in the request processing between SRF and DLL requests. In fact, for a typical request ”one for which the application DLL has been loaded and cached and the parsed stencil (if it s an SRF request) has been cached ”there s very little direct overhead in the ISAPI extension before or after invoking the request handler. Almost all the overhead comes from the creation of the request handler class itself. For a synchronous request (which is the typical case), the request handler class is created off a per-thread heap for maximum performance (we discuss per-thread heaps in more detail later in this chapter).

Once the request handler class has been created, the processing moves from the ISAPI extension to the application DLL and request handler class. For the purposes of this section, assume that the request handler will be doing SRF processing and that the parsed stencil has been cached. The ATL Server framework retrieves the parsed stencil from the cache and then begins invoking the tag methods for the rendering. The ATL Server framework overhead here is very small ”it s just the cost of walking the stencil tags and invoking the tag methods .

Because database processing is so common in Web applications, assume that the request handler is also doing some database processing during the request. For this section, also assume that database access is through the ATL OLE DB Consumer Templates. The main overhead involved in database access relates to opening database connections and building and executing the query. ATL Server provides facilities for caching database connections to minimize the cost of opening connections. For an application that makes good use of ATL Server s connection caching mechanism, the majority of the cost will be in the SQL statements that are executed in the Web request. Though we discuss some database performance issues later in this chapter, optimization of SQL statements is outside the scope of this book. However, the same considerations that apply to SQL optimization in general apply to the use of SQL within ATL Server.

Once the request handler has finished its processing and returned control to the ISAPI extension, ATL Server does its final processing, which usually involves informing IIS of the request completion (and may also involve writing some headers and content to the request) and freeing any memory allocated for the request (usually the request handler class and the ATL Server “specific information structure).

For a typical Web request, the ATL Server framework takes an additional 5 percent to 10 percent of the execution time over the portion of the execution time taken by IIS.

Now that we ve broken down a typical Web request into its parts from a performance perspective, you can look at how to optimize each portion ( specifically , how not to slow things down). Later on in this chapter, you ll look at other scenarios that occur frequently in Web development but aren t as common as this typical request.