28 Tips to improve ASP performance and appearance

Skills | performance

Introduction

Performance is a feature. You must design the performance beforehand, or you will have to rewrite the application later. That is, what are the good strategies to make activeserverpages (ASP) application performance the best?

This article describes the techniques for optimizing ASP applications and Visualbasic®scriptingedition (VBScript). This article discusses a number of pitfalls. The recommendations listed in this article have been tested in and out of other sites, with significant results. This article assumes that you have developed an ASP, including VBScript and/or JScript, Aspapplication, Aspsession, and other ASP-intrinsic objects (Request,Response , and Server) has a basic understanding.

Typically, ASP performance is largely dependent on a number of factors outside the ASP code itself. We don't list all the information in an article, and at the end of this article we list the resources that are related to performance. These links cover ASP and non-ASP topics, including activex® Data Objects (ADO), Component Object Model (COM), database, and Internetinformationserver (IIS) configurations. These are some of our favorite links-be sure to go and see.

Tip 1: Cache frequently used data on a Web server

A typical ASP page retrieves data from the back-end data store and then converts the results to Hypertext Markup Language (HTML). Retrieving data from memory is much faster than retrieving data from the back-end data store, regardless of the speed of the database. Reading data from a local hard disk is usually faster than retrieving data from the database. As a result, you can typically cache data on a Web server (stored in memory or on a disk) to improve performance.

Caching is a traditional way of exchanging time in space. If you're caching the right content, you can see a significant improvement in performance. For caching to be valid, data that is frequently reused must be saved, and a large (modest) overhead is needed to recalculate the data. If all of the cached data is stale, it can cause memory waste.

Data that is infrequently changed is a good candidate for caching because you do not have to worry about synchronizing the data with the database over time. combo box lists, reference tables, DHTML fragments, Extended Markup Language (XML) strings, menu items, and site configuration variables, including data source names (DSNs), Internet Protocol (IP) addresses, and web paths, are good candidates for caching. Note that you can cache the "representation" of the data without caching the data itself. If ASP pages are rarely changed and the cache is expensive (for example, the entire product catalog), you should consider producing HTML in advance, rather than showing it again in response to each request.

Where should the data be cached, and what caching policies are there? Typically, data is cached on the Web server's memory or disk. The next two tips tell the two ways.

Tip 2: Cache frequently used data in a application or Session object

ASPapplication and session objects provide a convenient container for caching data in memory. You can assign data to application and session objects, which remain in memory between HTTP calls. Session data is stored separately for each user, while application data is shared among all users.

When will the data be loaded into the application or session? Typically, data is loaded when the application or session is started. To load data during the application or session startup process, add the appropriate code to or. These functions should be in Global.asa, and if they are not, you can add them. You can also mount the data the first time it is needed. To do this, add some code (or write a reusable script function) to the ASP page to check whether the data exists, and if not, load the data. This is a traditional performance technique, called lazy computing, that does not calculate a value until you know it is needed. For example:

<%
FunctionGetEmploymentStatusList
Dimd
d=Application(?EmploymentStatusList?)
Ifd=??Then
'FetchEmploymentStatusListfunction(notshown)
'fetchesdatafromDB,returnsanArray
d=FetchEmploymentStatusList()
Application(?EmploymentStatusList?)=d
EndIf
GetEmploymentStatusList=d
EndFunction
%>


You can write similar functions for each block of data that you need.

In what format should the data be stored? You can store any variant type, because all script variables are variant types. For example, you can store strings, integers, or arrays. Typically, you will store the contents of an ADO recordset as one of these variable types. To get data from an ADO recordset, you can manually copy the data to a VBScript variable, one field at a time. Using an ADO recordset Persistence function GetRows (), GetString (), or Save () (ADO2.5) can be faster and easier. The details are beyond the scope of this article, but here is an example of a function that uses an array of returned recordset data:

'GetRecordset,returnasanArray
FunctionFetchEmploymentStatusList
Dimrs
Setrs=CreateObject(?ADODB.Recordset?)
rs.Open?selectStatusName,StatusIDfromEmployeeStatus?,_
?dsn=employees;uid=sa;pwd=;?
FetchEmploymentStatusList=rs.GetRows()?ReturndataasanArray
rs.Close
Setrs=Nothing
EndFunction


For a further improvement on the above examples, you can cache HTML as a list, not an array. The following is a simple example:

'GetRecordset,returnasHTMLOptionlist
FunctionFetchEmploymentStatusList
Dimrs,fldName,s
Setrs=CreateObject(?ADODB.Recordset?)
rs.Open?selectStatusName,StatusIDfromEmployeeStatus?,_
?dsn=employees;uid=sa;pwd=;?
s=?<selectname=??EmploymentStatus??>?&vbCrLf
SetfldName=rs.Fields(?StatusName?)'ADOFieldBinding
DoUntilrs.EOF
'NextlineviolatesDon'tDoStringConcats,
'butit'sOKbecausewearebuildingacache
s=s&?<option>?&fldName&?</option>?&vbCrLf
rs.MoveNext
Loop
s=s&?</select>?&vbCrLf
rs.Close
Setrs=Nothing'SeeReleaseEarly
FetchEmploymentStatusList=s'ReturndataasaString
EndFunction


Under the appropriate conditions, you can cache the ADO recordset itself in the application or session scope. There are two warnings:

If these two requirements are not guaranteed, do not cache the ADO recordset. In the following "non-agile components" and "Do not cache connections" techniques, we will discuss the dangers of storing COM objects in the application or session scope.

When you store data in a application or session scope, the data remains there until you programmatically change it, session expiration, or the Web application restarts. What if the data needs to be updated? To manually force updates to application data, you can access ASP pages that only administrators can access to update the data. Alternatively, you can automatically refresh the data periodically through functions. The following example stores a timestamp with cached data and refreshes the data after a period of time.