Wise ASP - ASP and JScript Coding Standards and Performance Tips
Staying on that bleeding edge can be a great kick, but it can also leave you scratching your head. You may have come up with something totally cool for your Web site -- but since no other Web site has the feature, you end up wondering where to get help. I am always looking for ways to improve the performance of Web pages and to improve on coding styles. I have been able to compile from different sources some great suggestions (some my own) from people on the Internet, including ways to improve ASP performance and style tips.File names
File names should be short, descriptive, lower case and contain no spaces. Consistent case will increase the speed of the web server by improving the caching mechanism. IIS thinks that "fileName.asp" and "filename.asp" are two different files, so it has to do a lot of wasted work. Avoid this by always writing filenames entirely in all lowercase.
SQL Notes
All SQL calls should use consistent case: this will increase the
speed of the database server by improving the caching mechanism.
The database server thinks that
"SELECT name FROM items"
and
"select name from items"
are two different queries, so it has to do a lot of wasted work.
Avoid this by always writing queries entirely in all lowercase
or else upper case for protected words (such as SELECT) and
lower case for all others. Do not use "SELECT *" in
production code. Instead select only the column names
that you need. This will improve your query speed and overall
web/database communication speed.
Be sure to close ADO Connection and Recordset
objects when you are done with them.
Important: Be very careful about accepting user input
and adding it to a query. User-entered apostrophes or percent
signs will mess up your query and can pose a security risk.
Always check all user input for "%" and "'".
Use Local Variables Whenever Possible
Local variables are variables that reside within subroutines and functions
(this is known as local scope). These variables are
compiled into numeric references and put in a table.
Local variable references can be resolved at compile time.
Global variables are resolved at run time. This means that
local-variable access is many times faster than global-variable access.
Also, undimensioned global variables are the slowest of all --
the first time an undimensioned global variable is used,
the entire object model is searched for an object with that named
property before a new one is created.
So use local-variables to get that better performance.
Copy Collections Values to Local Variables
If there are collection values that you are using more than once,
copy these values onto the client in the form of local variables.
This saves you a look-up operation on the collection each time
you use the value and will speed up your script.
Combine ASP Statements
Try not to intersperse HTML and script too much, if at all. Instead, try
to have blocks of script and few client-side HTML. Actually, the best
solution to this is write as much of your server-side ASP within
<script language=jscript runat=server> ... </script> To see more
details about this tip, go to my article.
global.asa
In order to make Application and Session work
in ASP, we use a single file name global.asa for each
"application". global.asa contains the state of the
application via the Application and Session object properties
and any global code the "application" requires to alter it.
This file resides in the directory on the server that is the root
of that application -- where the files that make up the application
are located. Any subdirectoires of the main application directory
are also part of the application, and the gloabal.asa
applies to their contents as well. This means you need to be
aware of the possibility of overlap between applications, and should
generally create separate directoires for each one. So when
we talk about an application in ASP, we are actually talking
about all the files in the same directory as global.asa, and
any of its physical subdirectories.
You can use the global.asa to gain
a significant speed improvement.
global.asa is not displayed to users but stores application-global
event information and objects.
This means the read from the .asp file happens once per server instead
of once per page per user. You can run a separate .asp
file to refresh the contents of the Application variable.
Confused about how to implement this? If the contents of the
cached information need to change, you can call
into an Administrator-access-only .asp file containing
script that can do an Application.Lock, update
the cached information and finally do an Application.Unlock.
Do not hardcode the dsn string, the database user id,
or the database password in your .asp files. Instead store
them in application variables in Application_OnStart().
SCRIPT LANGUAGE=JSCRIPT RUNAT=SERVER
function Application_OnStart()
{
Application("dbName") = "dbName"; \ Database Name(ODBC name,etc.
Application("dbUserID") = "userID"; \ Database User ID
Application("dbUserPw") = "password"; \ Database User Password
}
/SCRIPT
You can now easily change and maintain the dsn
information for an entire application.
Be Careful of the Session Object
You can use the Session object to store information that you
may need for a particular user-session. Variables that are
stored in the Session object are not discarded when the user
jumps between pages in the application. Instead, these
variables persist for the entire user-session. The Web server
automatically creates a Session object when a Web page from
the application is requested by a user who does not already
have a session. The server destroys the Session object when
the session expires or is abandoned. To avoid this, you can
turn off the Session feature.
Turning it off for the entire server is faster but drops a lot
of functionality. Instead, be very careful to use the Session
object only when you really need to.
If you use the Session object at all in your application,
be sure to use it as soon as possible in order to avoid
the Session object from being reset. In IIS, the session state
can be enabled on a per-application basis and it can
be disabled for specified .asp files.
Avoid Using Server Variables
Accessing server variables causes your Web site to make a special
request to the server and collect all server variables,
not just the one that you requested. This is akin to
needing to retrieve a specific item in a folder that
you have in that messy garage of yours. When you want
that one item, you have to go to the garage to get the folder
first, before you can access the item. This is the same
thing that happens when you request a server variable,
the performance hit occurs the first time you request a server
variable. Subsequent requests for other server variables
does not cause a performance hit.
Use Literal Paths
Try to avoid MapPath if at all possible. Instead, use the
literal path if you know it. Using MapPath requires IIS to
retreive the current server path, which means a
special request to IIS -- which in turn means (you guessed it) decreased performance.
Instantiate Objects Using the <OBJECT> Tag
If you need to refer to objects that may not be used,
instantiate them by using the <OBJECT> tag rather than
using Server.CreateObject. Using Server.CreateObject
causes the object to be created immediately. If you
don't use that object later, you end up wasting resources.
Use Client-Side Validation Abilities
If you are running a generation 4 browser, the browser
is capable of doing some validation for you.
Take advantage of this whenever you can.
Perform validation with your server-side scripting.
When all else fails, then you
can go ahead and access your database on the server.
But remember, whenever you access that database that lives on the
server, you are going to take a performance hit. This can be very
expensive if you have several values in a form that you are validating.
If you know that you will need to run some script on the client side,
go ahead and move the code to the client side for faster performance.
When you are running on the client, you have the processor(s) for
your use; the server has to use its processing power for
all of the requests it receives.
Use Server-Side Comments Instead HTML Comments
It does seem that if you remove all HTML comments (script comments are fine),
large sections of HTML text can be "block copied" to the client.
Of course, for your own edification (and to keep code
maintainence from being a nightmare) you need comments. So go ahead and use
server-side comments. Not only could you receive a perfomance
boost but you will keep your comments to yourself.
Not everyone needs to know your secrets.
Standards for "include" files:
You should use include files only when absolutely necessary. Do not put
too many functions into a file. Otherwise, compile time is much slower,
which hurts performance. Files that contain any asp code should be
named with the .asp file extension. This is for security reasons.
Use the .inc extension if the included file contains pure HTML and
no asp. Include files should not contain and <% , %> or <%@ tags.
Include files should have no main()
, and should not call
main(). Functions should be surrounded by <SCRIPT LANGUAGE=JScript
RUNAT=SERVER> and </SCRIPT> tags. All functions must have unique names,
and should not conflict with the names of functions in other files
which includes this file. All functions should be well documented.
