25+ ASP Tips to Improve Performance and Style

Len Cardinal, Senior Consultant, Microsoft Consulting Services ... This article assumes that you have a basic understanding of ASP development, including.
Télécharger le PDF
124KB taille 1 téléchargements 273 vues
commentaire
Report
All Products |

TechNet Home |

Site Map |

Events |

Downloads |

Personalize |

Support |

Search |

microsoft.com Home

Worldwide |

25+ ASP Tips to Improve Performance and Style Topics on this Page Introduction Tip 1: Cache Frequently-Used Data on the Web Server Tip 2: Cache Frequently-Used Data in the Application or Session Objects Tip 3: Cache Data and HTML on the Web Server’s Disks Tip 4: Avoid Caching Non-Agile Components in the Application or Session Objects Tip 5: Do Not Cache Database Connections in the Application or Session Objects Tip 6: Use the Session Object Wisely Tip 7: Encapsulate Code in COM Objects Tip 8: Acquire Resources Late, Release Early Tip 9: Out-of-Process Execution Trades Off Performance for Reliability Tip 10: Use Option Explicit Tip 11: Use Local Variables in Subroutines and Functions Tip 12: Copy Frequently-Used Data to Script Variables Tip 13: Avoid Redimensioning Arrays Tip 14: Use Response Buffering Tip 15: Batch Inline Script and Response.Write Statements Tip 16: Use Response.IsClientConnected Before Embarking on Long Trips Tip 17: Instantiate Objects Using the Tag Tip 18: Use TypeLib Binding for ADO and Other Components Tip 19: Take Advantage of Your Browser’s Validation Abilities Tip 20: Avoid String Concatenation in Loops Tip 21: Enable Browser and Proxy Caching Tip 22: Use Server.Transfer Instead of Response.Redirect Whenever Possible Tip 23: Use Trailing Slashes in Directory URLs Tip 24: Avoid Using Server Variables Tip 25: Upgrade to the Latest and Greatest Tip 26: Tune Your Web Server Tip 27: Do Performance Testing Tip 28: Read the Resource Links Len Cardinal, Senior Consultant, Microsoft Consulting Services George V. Reilly, Microsoft IIS Performance Lead Adapted from an article by Nancy Cluts Developer Technology Engineer Microsoft Corporation Updated: April 2000 Summary: This article presents tips for optimizing ASP applications and VBScript. Introduction

Performance is a feature. You need to design for performance up front, or you get to rewrite your application later on. That said, what are some good strategies for maximizing the performance of your Active Server Pages (ASP) application?

This article presents tips for optimizing ASP applications and Visual Basic® Scripting Edition (VBScript). Many traps and pitfalls are discussed. The suggestions listed in this article have been tested on http://www.microsoft.com and other sites, and work very well. This article assumes that you have a basic understanding of ASP development, including VBScript and/or JScript, ASP Applications, ASP Sessions, and the other ASP intrinsic objects (Request, Response, and Server). Often, ASP performance depends on much more than the ASP code itself. Rather than cover all wisdom in one article, we list performance-related resources at the end. These links cover both ASP and non-ASP topics, including ActiveX® Data Objects (ADO), Component Object Model (COM), databases, and Internet Information Server (IIS) configuration. These are some of our favorite links—be sure to give them a look. Tip 1: Cache Frequently-Used Data on the Web Server

A typical ASP page retrieves data from a back-end data store, then paints the results into Hypertext Markup Language (HTML). Regardless of the speed of your database, retrieving data from memory is a lot faster than retrieving data from a back-end data store. Reading data from a local hard disk is also usually faster than retrieving data from a database. Therefore, you can usually increase performance by caching data on the Web server, either in memory or on disk. Caching is a classic space-for-time tradeoff. If you cache the right stuff, you can see impressive boosts in performance. For a cache to be effective, it must hold data that is reused frequently, and that data must be (moderately) expensive to recompute. A cache full of stale data is a waste of memory. Data that does not change frequently makes good candidates for caching, because you don't have to worry about synchronizing the data with the database over time. Combo-box lists, reference tables, DHTML scraps, Extensible 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 presentation of data rather than the data itself. If an ASP page changes infrequently and is expensive to cache (for example, your entire product catalog), consider pregenerating the HTML, rather than repainting it for every request. Where should data be cached, and what are some caching strategies? Data is often cached either in the Web server's memory or on the Web server's disks. The next two tips cover these options. Tip 2: Cache Frequently-Used Data in the Application or Session Objects

The ASP Application and Session objects provide convenient containers for caching data in memory. You can assign data to both Application and Session objects, and this data will remain in memory between HTTP calls. Session data is stored per user, while Application data is shared between all users. At what point do you load data into the Application or Session? Often, the data is loaded when an Application or Session starts. To load data during Application or Session startup, add appropriate code to Application_OnStart() or Session_OnStart(), respectively. These functions should be located in Global.asa; if they are not, you can add these functions. You can also load the data when it's first needed. To do this, add some code (or write a reusable script function) to your ASP page that checks for the existence of the data and loads the data if it's not there. This is an example of the classic performance technique known as lazy evaluation—don't calculate something until you know you need it. An example:

Similar functions could be written for each chunk of data needed. In what format should the data be stored? Any variant type can be stored, since all script variables are variants. For instance, you can store strings, integers, or arrays. Often, you'll be storing the contents of an ADO recordset in one of these variable types. To get data out of an ADO recordset, you can manually copy the data into VBScript variables, one field at a time. It's faster and easier to use one of the ADO recordset persistence functions GetRows(),GetString()or Save()(ADO 2.5). Full details are beyond the scope of this article, but here's a function that demonstrates using GetRows() to return an array of recordset data: ' Get Recordset, return as an Array Function FetchEmploymentStatusList

Dim rs Set rs = CreateObject(?ADODB.Recordset?) rs.Open ?select StatusName, StatusID from EmployeeStatus?, _ ?dsn=employees;uid=sa;pwd=;? FetchEmploymentStatusList = rs.GetRows() ? Return data as an Array rs.Close Set rs = Nothing End Function

A further refinement of the above might be to cache the HTML for the list, rather than the array. Here's a simple sample: ' Get Recordset, return as HTML Option list Function FetchEmploymentStatusList Dim rs, fldName, s Set rs = CreateObject(?ADODB.Recordset?) rs.Open ?select StatusName, StatusID from EmployeeStatus?, _ ?dsn=employees;uid=sa;pwd=;? s = ?? & vbCrLf Set fldName = rs.Fields(?StatusName?) ' ADO Field Binding Do Until rs.EOF ' Next line violates Don't Do String Concats, ' but it's OK because we are building a cache s = s &? ? &fldName &?? & vbCrLf rs.MoveNext Loop s = s &?? & vbCrLf rs.Close Set rs = Nothing ' See Release Early FetchEmploymentStatusList = s ' Return data as a String End Function

Under the right conditions, you can cache ADO recordsets themselves in Application or Session scope. There are two caveats: ●

ADO must be marked Free-threaded

●

You need to use a disconnected recordset.

If you cannot guarantee that these two requirements will be met, do not cache ADO recordsets. In the Non-Agile Components and Don't Cache Connections tips below, we discuss the dangers of storing COM objects in Application or Session scope. When you store data in Application or Session scope, the data will remain there until you programmatically change it, the Session expires, or the Web application is restarted. What if the data needs to be updated? To manually force an update of Application data, you can call into an administrator-access-only ASP page that updates the data. Alternatively, you can automatically refresh your data periodically through a function. The following example stores a time stamp with the cached data and refreshes the data after a certain time interval.