To read the article online, visit

Increasing the Performance of your ASP Pages

Concerned about the performance of your ASP pages? On the Internet performance is key. Make your users wait too long and they will abandon your site for a more efficient one. While there are many ways to improve the performance of IIS, this article focuses on techniques you can employ to increase the performance of your ASP pages. Of course to do any kind of performance testing you must have a means to measure the time it takes for a given ASP page to execute.

One can write their own set of timing functions to precisely time the execution of ASP scripts. Luckily such a set of functions already exists and is freely available in the article Measuring Code Speed. Take a moment to check out that article and try out the timing code.

Here are some worthwhile tips to directly increase the performance of your ASP pages. With many of these tips you'll find percentages indicating how one performance tip increased the overall performance of an ASP page. Most of these numbers were taken from the article Enhancing Performance in ASP. (These numbers of referred to as a percentage of increase in performance. These percentages were figured taking the running time before the optimization and after. So, if a script took 10 milliseconds to run before the optimization and 5 milliseconds afterwards, a 50% performance increase would be reported.)

Add Response.Buffer = True to your ASP Code!
This single line of code turns buffering on in an ASP page. (Buffering can also be set site-wide in the IIS MMC; site-wide buffering is off by default in IIS 4.0 and on by default in IIS 5.0.) A buffer pages waits to send the HTML content to the client until the entire ASP script has been processed or it encounters a Response.Flush. This buffering increased performance because IIS doesn't need to bother sending any HTML information to the client until the entire ASP script has been processed. Buffering, which can yield around a 13% increase in ASP page processing, is described in more detail in the article: Buffer that Output.

Reference Columns in a Recordset Ordinally
When working with an ADO Recordset object, there are a number of ways to grab the value of a particular column. The most common way is to use the column's name. For example, if we had a Recordset object named objRS that had three columns, Name, Age, and Salary, we could display these contents of these three columns for the current row in the Recordset using the following code:

Employee's Name: <%=objRS("Name")%><BR>
Employee's Age: <%=objRS("Age")%><BR>
Employee's Salary: <%=FormatCurrency(objRS("Salary"))%>

These values can also be accessed ordinally. Each column is given an ordinal index starting at zero. Hence, these three columns could also be displayed with the slightly modified code:

Employee's Name: <%=objRS(0)%><BR>
Employee's Age: <%=objRS(1)%><BR>
Employee's Salary: <%=FormatCurrency(objRS(2))%>

While this leads to less readable code, it provides for better performance. In fact, tests done by 4Guys columnist Mike Shaffer indicate that a near 50% increase can be seen by referring to all ADO columns ordinally. For details on this experiment, read: Optimizing ADO Calls.

From alert 4Guys visitor Gary P.
While your tip about accessing recordsets with rs(4) for fast performance is true, in most cases, if more than one person is working on a site, it could get you in trouble. Someone else adding one field to the SQL string NOT at the end will throw off all your code. One addendum you might want to add is to use constants defined right next to the SQL for the field names. Then it would be less likely someone would update the SQL without also seeing the constants. Also makes it much easier to remember the answer to "Was title field 3 or 4?" Some comments wouldn't hurt either. Example:

  ' ALWAYS update field constants below when
  ' changing this SQL!
  strSQL = "SELECT FName, LName, Age from People"
  Const FNAME = 0
  Const LNAME = 1
  Const AGE = 2
  ' .... Load recordset here.

  Response.Write "First Name: " & RS(FNAME) & "<BR>"
  Response.Write "First Name: " & RS(LNAME) & "<BR>"

I think that's a nice compromise between performance and maintainability/readability...

Set EnableSessionState to Flase
By default, IIS prepares to maintain a user's Session on every page. Of course not every page works with session variables, but IIS is prepared nevertheless. If you know a particular page will not use any session variables you can explicitly tell IIS that it does not need to worry about maintaining session state. To do this, set the directive EnableSessionState to False. Like buffering, you can disable an entire site from needing to concern itself with session state through the IIS MMC. Disabling EnableSessionState on a page-by-page basis only leads to a meager 2% increase in performance, but, in my opinion, is worth it. (A near 8% increase can be seen an entire site's session state can be disabled through the IIS MMC.) For more information on EnableSessionState be sure to read: Using EnableSessionState

Use Option Explicit!
When Option Explicit is used, all variables must be explicitly declared before being used. This greatly enhances readability and prevents an entire class of silly typographical errors and bugs that can occur when Option Explicit is not used. Not only does Option Explicit lead to more readable and maintainable code, Option Explicit also increases performance by up to 10%! There is no reason why you shouldn't use Option Explicit on every ASP page! For more on Option Explicit be sure to read Using Option Explicit.

Well, those are some of the most important performance tips on an ASP-level. There are, of course, many ways to increase the performance of your Web server and COM object which indirectly lead to increased performance of your ASP pages. For more information on these these types of performance increases be sure to read the following articles:

Happy Programming!

Article Information
Article Title: Increasing the Performance of your ASP Pages
Article Author: Scott Mitchell
Published Date: Wednesday, June 07, 2000
Article URL:

Copyright 2017 QuinStreet Inc. All Rights Reserved.
Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers