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.)
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,
Salary, we could display these contents of these three
columns for the current row in the Recordset using the following code:
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:
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:
I think that's a nice compromise between performance and maintainability/readability...
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
False. Like buffering, you can disable an entire site
from needing to concern itself with session state through the IIS MMC. Disabling
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
EnableSessionState be sure to read: Using
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
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
be sure to read Using
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:
- Speed and Optimization Resources
- Server Optimizations
- Speeding Up ASP Pages with Caching
- Cursor and LockType Performance Issues
- Performance Tuning the Web Server
- Tuning IIS 4.0 for High-Volume Sites