Performance Author: Green Apple Studio compilation
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 ;
