Optimizing IIS for Peak Performance

GETTING THE MOST FROM YOUR WEB APPLICATIONS AND SERVER

Every time you load new software on a server, you have to address the performance of other applications on the same server, as well as the problem of optimizing that application's performance. Internet Information Server (IIS) runs on a server and consumes resources as other applications do. However, IIS can attract more traffic than many other applications. High traffic can negatively affect the server's operation if you use IIS in an Internet environment. To get the most from your Web server and ensure that IIS doesn't consume every system resource, developers have to tune Web applications and you have to tune your Web server. By controlling variables and ActiveX components and taking advantage of Windows NT's and IIS 4.0's built-in performance tuning features, you can make IIS perform at its optimum efficiency.

Optimizing Your Web Applications
The performance of your Web applications plays a direct role in the performance of your IIS server. As a result, you might want your inhouse development team to improve the code you're already using for your Web applications. By rewriting an application, developers can improve performance by a factor of 10 to 1000. Let's look at how developers can control two types of variables and ActiveX components to improve performance when writing Web-based applications.

Session and application variables. IIS 3.0 and Active Server Pages (ASP) introduced two types of variables (session variables and application variables) that are extremely useful in constructing Web-based applications. The ASP stores session variables as part of a user's session object and makes these variables available at any point in the Web application, but only for the duration of the user's session. ASP stores application variables as part of the application object and makes these variables available at any point in the Web application.

In addition to being useful, session variables are easy to use. For example, you can write an application so that it obtains and stores a username for later use. You simply add a statement similar to the following to the ASP code:

<%
   Session("UserName") = "Ken"
%>

You can use application variables in the same way. For example, you can write an application so that it obtains and stores a company name. You simply add a statement similar to the following to the ASP code:

<%
   Application("CompanyName") = "32X Corporation"
%>

Session variables exist only within one user's session, so you can't access them across multiple user sessions. In contrast, application variables can exist across multiple user sessions, so you can access them at any time from any page in the application.

Both session variables and application variables can affect the performance of your Web applications, depending on the type of data you place in each type of variable. If you place a lot of data in a session variable, every user who accesses the Web application consumes memory for that data. This memory usage can quickly add up because ASP stores both session and application objects in RAM on the IIS server. So, if you store 2KB of data in a session variable and your application hosts 400 users, just that one session variable uses about 800KB of RAM!

The ASP process doesn't duplicate data stored in an application object for each user, but this data can still cause problems. For example, if you create a set of Web pages on your Web server that contain a lookup using the Visual InterDev Data Form Wizard, the generated code will include statements similar to the following:

avarTestCustomers = rsTestCustomers.GetRows()
Application.Lock
Application(strDFName & "_Lookup_TestCustomers") = avarTestCustomers
Application.Unlock

This code loads all the values in the rsTestCustomers lookup record set into an application variable. This functionality is ideal for importing data such as a list of every state in the US. But what happens if you select a lookup for a client database that contains 1 million customers? All 1 million entries go into memory in the application objectnot exactly what you're looking for. Although you can use this mechanism with the session object to hold data from a database, you must be careful to avoid overloading the server's memory.

Session lifetime is related to the session object and is another area that can affect the performance of your Web application. (Session lifetime is how long a session stays active after a user stops interacting with it.) A SessionTimeout parameter in the Registry controls the session lifetime, and the default SessionTimeout value for IIS 3.0 and IIS 4.0 is 20 minutes. You can analyze your users' activity in your Web application and reduce this value as low as possible to minimize the amount of time that each session consumes resources. A developer can change the SessionTimeout value on the fly for different users to customize the users' session timeout based on their needs and reduce the potential load on IIS and the system's resources.

To change the session lifetime for IIS 3.0, you must go to HKEY_LOCALMACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ and change the SessionTimeout value. If you're using IIS 4.0, you can use the IIS Manager to change this parameter. First, select the virtual directory that contains the Web application you want to change this setting for, and click Configuration to display the Application Configuration dialog box. Next, select the App Options tab, as you see in Screen 1. You can change the session timeout by entering a new value (in minutes) in the Session timeout box.

A final tip about using session variables in your Web applications: You can do away with the session overhead by not using session variables. If you eliminate sessions, your developers must use techniques such as passing variables with a URL as part of the QueryString, or using HTML forms to pass information between pages and code. With IIS 4.0, you can run session-less Web pages if you enter the following directive in each page:

<%@ EnableSessionState=False %>

If you place this directive in the first page of your Web application that a user connects to, the Session_OnStart procedure won't activate until the user navigates to a page without this directive. This directive delays the resource intensive session startup until a particular page needs it. You can also turn off session management for the application to further reduce the load the application places on the server. To turn off the session management, clear the Enable session state check box in the Application Configuration dialog box.

In addition to reducing the need for system resources, another advantage of not using sessions is that you can host the Web application on multiple servers and use a smart router or similar technology to shuffle users to the server with the lightest load. Session and application variables exist only on the server running the Web application, but URL variables and HTML form variables can cross servers. With the latter types of variables, IIS passes any variable data with the HTML stream, so your servers can efficiently handle user requests. You must make sure the servers sharing the Web load can access all resources (e.g., databases, Open Database ConnectivityODBCinformation, and files) the Web application requires. (For more information about maintaining application state information using ASP on one or more servers, go to http://www.15seconds.com/Issue/page.asp?Issue_Id=115.)

Previous [1] 2 Next