Skip to page content or skip to Accesskey List.
Search evolt.org
evolt.org login: or register

Work

Main Page Content

ASP Performance tips

Rated 3.92 (Ratings: 2) (Add your rating)

Log in to add a comment
(2 comments so far)

Want more?

 
Picture of MartinB

Martin Burns

Member info | Full bio

User since: April 26, 1999

Last login: March 30, 2010

Articles written: 128

Using ASP on a busy server? Finding that it can't cope? Try our tips for making everything run faster, smoother and altogether more froody.

Performance goals vary from application to application. You should set your goals to correspond with your expected user traffic. In general, you should aim for 20 pages or more per second with less than 30 percent CPU utilization, and response times of 10 seconds or less.

  • Retrieving values from collections is relatively slow. Store retrieved values in local variables if you need to access them more than once.
  • Avoid using server-side #include directives to include large lists of constants.
  • Use the new <METADATA> tag to import type-library constants into global.asa.
  • Avoid using Server.CreateObject. Use <OBJECT> tags instead.
  • Group multiple Response.Write statements, and delimit them with one set of <% %> delimiters.
  • Avoid redimensioning VBScript arrays.
  • Use only one scripting language per page.
  • Buffered responses (Response.Buffer=True) are faster than unbuffered ones (although they can appear less responsive).
  • Use Response.IsClientConnected during the processing of long scripts. This property determines if the client has disconnected from the server since the last Response.Write, and improves application responsiveness during times of peak usage.
  • Use components to encapsulate business logic rather than complex script. Convert dynamic ASP output to static HTML using the ASP2HTM component wherever possible. (ASP2HTM is included on the Internet Information Server (IIS) Resource Kit CD.)
  • Store commonly requested, unchanging content in memory using an application-scope Dictionary object. Avoid using Session_OnEnd event procedures, if possible.
  • Disable the Session object on a page-by-page basis with the
    <%@
    EnableSessionState=False %>
    statement. This declarative allows ASP to process scripts concurrently, rather than sequentially.
  • Write client scripts that don't require roundtrips to the server. Distribute work to the client, such as form input validation. Use the Browser Capabilities component (MSWC.BrowserType) and customize client-side scripts to take advantage of the browser, incorporating such technologies as DHTML, client-side script, and ActiveX? controls.
  • Focus your optimization efforts on the most common paths through your site or application. You can determine user behavior with IIS service logs and the Usage Import and Report Writer component of Site Server Express.
  • Set Response.Expires appropriately so that proxy servers can intelligently cache information that doesn't change often.
  • Optimize the use of ADO Connection objects, with ODBC connection pooling and stored procedures.
  • Measure system performance with tools such as Task Manager, NetMon, and PerfMon. Measure Web capacity with WCAT. Profile portions of your ASP script with the ASP Tracer component. For more information see the IIS Resource Kit.
  • Try to keep one ASP page to One application. Use SQL stored procedures wherever possible.
These tips are culled from MSDN, where there may be even more.

Martin Burns has been doing this stuff since Netscape 1.0 days. Starting with the communication ends that online media support, he moved back through design, HTML and server-side code. Then he got into running the whole show. These days he's working for these people as a Project Manager, and still thinks (nearly 6 years on) it's a hell of a lot better than working for a dot-com. In his Copious Free Time™, he helps out running a Cloth Nappies online store.

Amongst his favourite things is ZopeDrupal, which he uses to run his personal site. He's starting to (re)gain a sneaking regard for ECMAscript since the arrival of unobtrusive scripting.

He's been a member of evolt.org since the very early days, a board member, a president, a writer and even contributed a modest amount of template code for the current site. Above all, he likes evolt.org to do things because it knowingly chooses to do so, rather than randomly stumbling into them. He's also one of the boys and girls who beervolts in the UK, although the arrival of small children in his life have knocked the frequency for 6.

Most likely to ask: Why would a client pay you to do that?

Least likely to ask: Why isn't that navigation frame in Flash?

Submitted by btallman on November 3, 1999 - 17:28.

You mention that storing a Dictionary Object in an Application level variable and sharing information that way is a good way to reduce overhead. That would be true, except that the Dictionary object is apartment threaded, not free/both, and as such, it can't be stored in an Application level var... Good idea though...

login or register to post comments

Submitted by sgd on November 19, 1999 - 12:09.

The people that are Caprock Consulting have a Dictionary object that is intended to replace the oem one for precisely that very reason. Their's is thread safe and marked as "Both" in the registry, and I've had good luck with it....

login or register to post comments

The access keys for this page are: ALT (Control on a Mac) plus:

evolt.orgEvolt.org is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.