web application, web application development,ajax application build own web,web site application development, building web application,application development services site web,

Delays while delivering web applications may cost you your business. One can not control the user's bandwidth but then efforts should be made towards optimizing the ASP sites to deliver excellent performances.

There are many aspects that affect the performance level of ASP. Some of them are as follows:

High quality coding practices
Languages used
Various processes like OpenGL screen savers that run on the server
Available bandwidth
Performance of the server like speed of the processor, RAM etc.
Using COM objects instead of ASP script
Stored procedures versus inline SQL
Database connection model and connection pooling.

This article deals with the important aspects that affect the performance level of ASP pages. The solutions to these performance affecting factors can be applied to large and complicated or lean and simple websites by everybody.

Script Size:

ASP scripts are highly useful for gathering information and planning the output. Each line of the script is interpreted so longer the page, longer is the implementation period.

Following are few ideas as what to do in case of longer ASP script page;

Use Response.IsClientConnected for lengthy scripts. This will prevent your CPU from wasting cycles in case the client is not connected.
Divide the long script into different segments like distinct user, logic and data services. Sometimes the procedures are very lengthy due to which the script becomes so long. What you can do is divide your script into smaller components on the basis of their functioning.
Alter the long script into server-side module. Make a Visual Basic DLL or an ActiveX element from modern Windows programming language and register on your server. By doing this you not only get speed but also protection for your software specifically when the ASP site is being delivered to a third-party.
#include script size also affects the ASP script length. When you #include a file the entire file gets loaded as it is on the ASP file. #include files with all the methods and definitions get cached entirely by ASP which then causes unproductive searches when a method is called in. IN this case the #include files must be divided into smaller sections.

Combination of ASP and HTML:

There is always jump from ASP to HTML while making tables and using an if statement.

For example:

Making a table:

<table>
<tr><td>Name< / td><td>Number< / td><td>Department< / td>< / tr>
<tr><td>
<%=RS("Name")%>
< / td><td>
<%=RS("Number")%>
< / td><td>
<%=RS("Department")%>
< / td><tr>< / table>

Using an if statement:

<%
If not Session("DBOpen") then
%>
<h1>Database not connected< / h1>
<%
Else
%>
<h1>Database open< / h1>
<%
End If
%>

In both of these cases, the performance can be enhanced by keeping the blocks of ASP server-side script together and by using Response.Write to produce the HTML code like

<%
If not Session ("DBOpen") then
Response.Write "<h1>Database not connected< / h1>"
Else
Response.Write "<h1>Database open< / h1>"
End If
%>

This definitely improves the ASP script performance.

Maintaining the state across Session:

An excellent feature is to maintain the state across the session in ASP. These features however do affect the ASP performance. These sessions are restricted to single servers and thus do affect the quality of the website. Session utilize resources for each user. Do not place huge data into the Session object. Sessions are preserved in IIS and they occupy the memory space until and unless the session expires either when it times out or when the browser is closed down. Resources diminish if many users are using the application.

Accessing the database:

Although accessing the database through a web application is beneficial it does affect the ASP performance. Hence is essential to ensure the ill effect on the performance is as meager as possible. This can be done in following ways:

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.

Dos and Don'ts of ASP Coding:

For objects that you don't use frequently but would refer to when the need arises use the <OBJECT> tag instead of Server.CreateObject. Server.CreateObject creates the object immediately thus wasting your resources which will not be the case with <OBJECT> tag.
Depending on the applicability, use client-side validation of user input to reduce the number of HTTP round trips. When the browser is fully featured use it powers to clean the server-side of unwanted resources and to make space for far more important tasks.
Session_OnStart or Session_OnEnd methods need to be understood before application. Do not apply empty Session_OnStart or Session_OnEnd methods. No code is involved in these methods but their mere existence means time is spent on calling them.
Do not redimensionize arrays as it is more effective to assign the full size of the array after it is initialized as it helps in achieving the advantage of speed.
Using COM objects instead of ASP script (if possible)
Do not use the Server.MapPath application unless required as you will be wasting server time. Ensure you utilize qualified paths while installing your website to speed up the performance.
Local variables are easily accessible then public variables by the ASP scripting search engine thus enhancing the performance.

Enhancing the smooth performance of ASP application will ensure the proper functioning of your website.

This article has been compiled by the content development team at Pegasus InfoCorp which pulls subject matter specialists from different work domains. They can be contacted through the Pegasus InfoCorp website at info@pegasusinfocorp.com. Pegasus InfoCorp is an India based web design, web development and online/ offline software development company. Please visit http://www.pegasusinfocorp.com to read more articles and know more about us!

Other companies and organizations are welcome to reprint this article on their websites provided the following conditions are met.