What is the best choice for improving ASP performance (ii)

Performance

Should buffers be turned on?

To start the buffer with a script program
When you include Response.buffer=true at the top of the ASP script, IIS caches the contents of the page.

<% OPTION EXPLICIT
Response.Buffer = True
Dim FirstName
...

Fragments of/app1/buffer__1.asp

Previous best (reaction time) = 7.05 msec/page
Reaction time = 6.08 Msec/page
difference = -0.97 msec (down 13.7%)

Performance has been greatly improved. But wait, there's a better one.

To configure the boot buffer from the server

Although the buffer is started by default in IIS 5.0, it must be manually started in IIS 4.0. To locate the Properties dialog box for the site, select the configuration button from the Home Directory tab. Then, under App options, select Enable buffering. For this test, the Response.Buffer statement was removed from the script.

The former best = 7.05 msec/page
Reaction time = 5.57 Msec/page
difference = -1.48 msec (down 21%)

At the moment, this is the quickest response we've got, which is 21% less than the time we had in the best case. From now on, our future tests will have to use this reaction time as the benchmark.

Review and observation

Buffers are a good way to improve performance, so it is necessary to set the buffer to the default value of the server. If for some reason, the page does not correctly make the buffer run, only need to response.buffer=false command. One disadvantage of buffers is that users cannot see anything from the server until the entire page is processed. As a result, it is a good idea to occasionally call a response.flush to update the user during the processing of a complex page.

Now there is another addition to our rule: always turn on the buffers through the server settings.

Should you consider adding comments to your ASP code?

Most HTML developers know that it's not a good idea to include HTML annotations, which in the first place increases the size of the data being transferred, and second, they simply provide information to other developers about your page's organization. But what about the comments on the ASP page? They never leave the server, but they do increase the size of the page, so you have to decompose it with ASP.

In this test, we added 20 comments, each with 80 characters and a total of 1600 characters.

<% OPTION EXPLICIT
'-------------------------------------------------------------------------------
... Lines ...
'-------------------------------------------------------------------------------
Dim FirstName
...

/app2/comment_1.asp Fragment

Benchmark = 5.57 Msec/page
Reaction time = 5.58 Msec/page
difference = +0.01 msec (Increase 0.1%)

The results of the test are amazing. Although annotations are almost twice times the size of the file itself, their presence does not have a significant impact on the reaction time. So, we can follow the following rules:

An ASP annotation has little or no impact on performance as long as it is moderately used.

Should the default language be explicitly set for the page?

The IIS processing VBScript is the default setting, but I see that in most cases the language is explicitly set to VBSCRIPT in the <% @LANGUAGE =vbscript% > declaration. Our next test will examine how the presence of this declaration affects performance.

<%@ language=vbscript% >
<% OPTION EXPLICIT
Dim FirstName
...

/app2/language1.asp fragment.

Base value = 5.57 Msec/page
Reaction time = 5.64 Msec/page
difference = +0.07 msec (Increase 1.2%)

As you can see, statements that contain language have a slight impact on performance. So:

* Set the default language configuration of the server to match the language used on the site.
* Do not set a language declaration unless you use a Non-default language.

Should the session state be closed if not required?

There are many reasons to avoid using the session context of IIS, which can already be independent of an article. The question we are trying to answer now is whether closing the session context is helpful when the page is not needed. In theory, it should be, because there is no need to use the page to sample the session context.

As with buffers, session state has two configuration methods: Scripting and server settings.

To close the session context with a script

For this test, to close the session context in the page, I add a session state declaration.

<%@ EnableSessionState = FALSE% >
<% OPTION EXPLICIT
Dim FirstName
...

/app2/session_1.asp fragment.

Base value = 5.57 Msec/page
Reaction time = 5.46 Msec/page
difference = -0.11 msec (down 2%)

Only through such a small effort to get a good progress. Now look at part two.

Close session context through server configuration

To close the session context on the server, go to the Properties dialog box for your site. Select the configuration button on the Home Directory tab. Then, under App options, cancel the "Enable Session state" option. We run the test without a enablesessionstate declaration.

Base value = 5.57 Msec/page
Reaction time = 5.14 Msec/page
difference = -0.43 msec (down 7.7%)

This is another significant improvement in performance. So our rule should be to always turn off session state at the level of the page or application, if not required.

Does using option Explicit make a real difference in performance?

Set option Explicit at the top of an ASP page to require all variables to be declared on the page before they are used. There are two reasons for this. First, applications can handle the access of variables more quickly. Second, this will prevent us from accidentally using the variable's name. In this test we remove the Dim declaration of Option Explicit references and variables.

Base value = 5.57 Msec/page
Reaction time = 6.12 Msec/page
difference = +0.55 msec (9.8% Increase),

Although some lines of code have been removed from the page, the response time is still increasing. So while using Option Explicit can sometimes be time-consuming, it has a significant effect on performance. So we can add one more rule: Always use Option Explicit in VBScript.

Should script logic be placed in subroutines and function areas?

It is a good way to organize and manage code with functions and subroutines, especially when a code area is used more than once in a page. The disadvantage is to add an extra function call to do the same work on the system. Another problem with subroutines and functions is the scope of the variable. In theory, it is more efficient to specify variables within a function area. Now let's take a look at how these two things work.

To move a Response.Write statement into a subroutine

This test simply moves the Response.Write statement into a child program area.

...
Call Writetable ()
SUB writetable ()
Response.Write ("< HTML >" & _
"< head >" & _
...
"< TR >< TD >< B >EMail:</b ></td >< td >" & EMail & "</td ></tr > "& _
"< TR >< TD >< B >birth date:</></td >< td >" & Birthdate & "</td > </tr > "& _
"</table >" & _
"</body >" & _
"End SUB

/app2/function1.asp Fragment

Base value = 5.57 Msec/page
Reaction time = 6.02 Msec/page
difference = +0.45 msec (8.1% Increase)

As expected, subroutine calls add an extra burden to the page.

Move all scripts into the subroutine

In this test, both the Response.Write statement and the variable declaration are moved into a child program area.

<% OPTION EXPLICIT
Call Writetable ()
SUB writetable ()
Dim FirstName
...
Dim Birthdate
FirstName = "John"
...
Birthdate = "1/1/1950"
Response.Write ("< HTML >" & _
"< head >" & _
"< title >response test</title >" & _
""< BODY >" & _
"< H1 >response test

"< table >" & _
"< TR >< TD >< B >first name:</></td >< td >" & FirstName & "</td > </tr > "& _
...
"< TR >< TD >< B >birth date:</></td >< td >" & Birthdate & "</td > </tr > "& _
"</table >" & _
"</body >" & _
"End SUB

/app2/function2.asp Fragment

Base value = 5.57 Msec/page
Reaction time = 5.22 Msec/page
difference = -0.35 msec (6.3% lower)

Very interesting! Although moving a variable to a function range adds an extra function call, it actually improves performance. We can also add the following rules:

* On a page, if the code is to be used more than once, the code is marshaled into the function area.
* Move the variable declaration to the function scope when appropriate.

What is the effect of using the Include file?

An important function of ASP programming is to include code from other pages. With this feature, programmers can share functions on multiple pages, making the code easier to maintain. The disadvantage is that the server must assemble pages from multiple sources. Here are two tests that use the include file.

Include files that use inline code

In this test, a small piece of code is moved to an include file:

<% OPTION EXPLICIT
Dim FirstName
...
Dim Birthdate
FirstName = "John"
...
Birthdate = "1/1/1950"
% >

<!--#include file= "inc1.asp"-->

/app2/include_1.asp Fragment

Base value = 5.57 Msec/page
Reaction time = 5.93 Msec/page
difference = +0.36 msec (6.5% Increase)

It's not surprising. The load is formed using the include file.

Using include files in the function area

Here, the code is wrapped in a subroutine in an include file. The Include reference is made at the top of the page, calling the subroutine at the appropriate location of the ASP script.

<% OPTION EXPLICIT
Dim FirstName
...
Dim Birthdate
FirstName = "John"
...
Birthdate = "1/1/1950"
Call Writetable ()
% >

<!--#include file= "inc2.asp"-->

/app2/include_2.asp Fragment

Base value = 5.57 Msec/page
Reaction time = 6.08 Msec/page
Difference =+0.51 msec (9.2% Increase)

This has a greater impact on performance than functions calls. Therefore, the include file is used only when the code is shared between pages.

How much load will be formed when error handling is performed?

Error handling is necessary for all real applications. In this test, the error handle is invoked by calling the On Error Resume next function.

<% OPTION EXPLICIT
On Error Resume Next
Dim FirstName
...

/app2/error_1.asp Fragment

Base value = 5.57 Msec/page
Reaction time = 5.67 Msec/page
difference = 0.10 msec (1.8% Increase)

As you can see, the error handle comes at a price. We can make the following suggestion: Use the error handle only if it occurs outside of the test or control capability. A basic example is the use of COM objects that access other resources, such as ADO or FileSystem objects.

Does setting a context handle have an impact on performance?

When an error occurs, setting a context handle on the page allows the script to reverse the operation. This is set by using a processing declaration on the page.

<%@ TRANSACTION = REQUIRED% >
<% OPTION EXPLICIT
Dim FirstName
...

/app2/transact1.asp Fragment

Base value = 5.57 Msec/page
Reaction time = 13.39 Msec/page
difference = +7.82 msec (140.4% Increase)

Ah! The most dramatic result of this reality. So be aware of the following rule: Use the processing context only if two or more operations are executed as a unit.