I once saw a T-shirt which read, "It doesn't matter what the problem is - the answer is more power!". That's so true in computing; no matter if we're running the latest Gigahertz processor, we could always do with more RAM or disk space or another processor or a faster Ethernet connection or something else!
April 25, 2000
This is especially true when delivering Web applications. Any delays between an impatient user's button click and the results coming up on their screen could mean the user goes elsewhere - and if you're running a business, then this could be a potential loss of sales.
We may not have any control over the user's bandwidth, but we can certainly try to optimize our ASP sites to deliver the best performance.
Factors
Firstly, what factors might affect the performance of ASP? Unfortunately, there are a lot. For example:
Bandwidth available
Server performance (processor speed, RAM)
Other processes running on the server (like one of those OpenGL screen savers … !)
Database connection model, and connection pooling, let alone the database itself (e.g. Oracle vs SQL Server vs Access)
Language used (for some functions, I hear that Perlscript can outperform VBScript)
Stored procedures vs inline SQL
Using COM objects rather than an ASP script
Good coding practices
These are just a few. We could also look at tuning the Web server for "best" performance - but this can be an art form, and there are lots of variables.
Some of the above factors might be common sense, but others can be very complex issues in themselves. What to do? Well, in this article, rather than attempt to explain each and every thing that can have a bearing on the performance of your ASP pages, let's look at some of the main things we can do to shave off milliseconds. These are things we can all apply to our sites, whether they are large and complex, or lean and straightforward, and whether we are technical Web gurus or perhaps just starting off in our ASP delvings.
ASP script size
Are your scripts pages (and other pages) long? This is going to throttle you right from the start. ASP scripts are really very useful for gathering information and for formatting output. However, scripts are also interpreted line by line and so the longer your script, the longer the execution time.
If you have a huge ASP script, what can you do about it? Here are a few suggestions:
Convert it into a server-side component. That's right, make a Visual Basic DLL - or an ActiveX component from any modern Windows programming language - and register this on your server. A quick tutorial on this can be found at http://www.webdevelopersjournal.com/articles/activex_for_asp.html. Not only can an ActiveX component deliver quicker speed - being compiled - but also it can provide greater protection for your software, especially if you are delivering your ASP site to a third party for hosting.
Partition the script into distinct user, logic and data services. After all, just why is your script so long? Do you really have a huge, lengthy procedure? Quite likely, there are sections which access a data source, sections that manage user input and output formatting, and sections which perform the business rules of your application. It's possible that you can partition the script into smaller modules that separate these distinct functions. Actually, if you do this, you might even find some redundancy in your code: if you render several tables, for example, you could write one generic function to write a table, and just call it several times.
Related to the issue of ASP script size is that of #include'd script sizes. When you #include a file, the entire file is loaded, just as if it existed - in entirety - in the ASP file where it was #include'd. So, if you have a lengthy #include file that defines all sorts of global methods and definitions, be aware that these are being loaded on every #include, whether you need each method and definition for each ASP file or not. ASP caches the entire expanded code, and this can cause inefficient searches when a method is called. In this case, the #include files must be stripped down to smaller, modular files.
Be sure to use Response.IsClientConnected if your script is lengthy. This means your CPU can avoid wasting cycles if the client is no longer connected.
Interspersing of ASP and HTML
Everybody does this - we switch between ASP and HTML when rendering tables. For example,
Another common example is when using an if statement -
<%
If not Session("DBOpen") then
%>
<h1>Database not connected</h1>
<%
Else
%>
<h1>Database open</h1>
<%
End If
%>
In both these cases, the script's performance can be improved by keeping blocks of ASP server-side script together, and using Response.Write to generate our HTML code, like so -
<%
If not Session ("DBOpen") then
Response.Write "<h1>Database not connected</h1>"
Else
Response.Write "<h1>Database open</h1>"
End If
%>
This can genuinely show measurable performance improvement.
Session state
Undoubtedly, the ability to maintain state across a session in ASP is a great feature. However, it does impact your performance. Clearly, scalability of your Web site becomes an issue because sessions are restricted to single servers. However, a session does consume resources for each user.
If you're not using session variables - and actually you might not need to; using hidden form fields or query strings can sometimes do the trick - then you should disable session state. You can do this with the declarative
@EnableSessionState = False
and then ASP won't check for session information.
If you do rely on session state, avoid placing large amounts of data into the Session object. Sessions in IIS are persistent, and the memory allocated to a session will not be freed until the session has been terminated or has timed out. So - if your application is used by many concurrent users, your resources could become depleted.
Database access
Database accesses will slow down your ASP application - although the performance hit in this regard is well worth it, because of all the benefits that you receive from tying in a database to a Web application. So, since we're already taking a performance hit when connecting to and querying a database, let's make sure it's the smallest possible performance hit.
Make sure your databases are indexed, because this can provide an immediate performance improvement on your application. Also, be sure to run Update Statistics on your database server to help it keep track of the distribution of your data. Then, your database can make alterations to query execution plans based on this information.
Where possible, take advantage of stored procedures rather than SQL queries because these must be compiled repeatedly.
Check your SQL statements to make sure you're filtering data at the query level - rather than getting back more data than you need and filtering through it in ASP. Most everyone knows about the SQL 'where' clause, but I think the 'having' clause is often neglected when using aggregate functions. After all, let SQL do the work it was designed to do - let it join, sort, group and filter data.
If you can - and any serious business should - use SQL Server, not Access. Access is only a file-based database and does not handle multiple users well.
Use OLEDB and a DSN-less connection when you can, because these have been shown to demonstrate best performance with many concurrent connections. Don't use DAO or RDO because these are intended primarily for single-client application processes. ADO is designed and tested for Web use.
Explicitly set a cursor and locktype when creating recordsets. The cursor determines how the recordset handles updates to the dataset that it is currently working on, and the locktype determines how the recordset will perform updates. Understand and experiment with the different combinations to see how your database performance might vary. If you only want to make a single pass through the data, then the default cursor (forward only, read only) gives fastest performance with the least overhead.
Each time you reference an ADO variable, you expend clock cycles which might prove valuable. So, if you refer to a recordset field several times in one page, you can see a big performance boost if you copy database results into local variables. Then, use the local variables to display the value on your page.
ASP coding issues
Do not provide empty Session_OnStart or Session_OnEnd methods. These must be interpreted, and although there is no code in the body of the method, the fact that the methods exist means time is spent trying to invoke them.
Use client-side validation of user input, where possible, to minimize the number of HTTP round-trips required. If the browser is full-featured, use its power to free up server-side resources for more critical tasks.
Use local variables, and avoid public variables. Local variables can be accessed quicker by the ASP scripting engine than public variables, because the entire namespace doesn't have to be searched.
Avoid redimensioning arrays. It is more efficient to simply allocate the full size of the array when it is first initialized. You may waste some memory, in this case, but you do gain a speed advantage.
If you need to refer to objects that may not actually be used, instantiate them by using the <OBJECT> tag rather than Server.CreateObject. Using Server.CreateObject causes the object to be created immediately, whereas this isn't the case with the <OBJECT> tag. If you don't use the object later, you won't waste resources with <OBJECT>.
Turn on 'OPTION EXPLICIT'. In VB and VBScript you can use a variable without explicitly declaring it. Turning on this option helps identify undefined variables - which may well be typos - and helps increase performance. Undeclared local variables are slow, because the entire namespace must be searched to see if the variable exists before it is created. Get rid of them. Make everything explicit. It's good practice, it may trap typos, and it is faster.
Don't use Server.MapPath unless you really need to. This is just another request the server has to process. Use fully qualified paths when deploying your Web site, to speed performance.
Check How You're Doing
Microsoft advocate that performance goals should correspond with your expected user traffic, and in general, you should aim for 20 pages or more per second with less than 30% CPU utilization, and response times of 10 seconds or less. You can measure your system performance with tools such as the Task Manager, NetMon and PerfMon. Measure Web capacity with WCAT (Web Capacity Analysis Tool). Profile portions of your ASP script with the ASP Tracer component. For more information on this, see the IIS Resource Kit. There is also a lengthy user guide for WCAT, with a download link, on the MSDN online Web workshop site. http://msdn.microsoft.com/workshop/server/toolbox/wcat.asp
Be sure to get this tool, if you're serious about maximizing your ASP performance.
By striving to maximize your ASP application's performance, your Web application will glide along that much faster. There's no need to take a performance hit when you don't really need to!
David Williams is a computer consultant in Newcastle, Australia. Recent projects include an ASP-based task logging system for a University help desk environment, and 'hack-proofing' an evaluation version of a package to manage mobile phone shops.
