ASP developers are constantly striving to achieve better performance and scalability in their design projects. Fortunately, many books and sites provide good suggestions in this regard. However, these suggestions are based on the conclusions drawn from the structure of the ASP platform, and there is no measurement for the actual performance improvement. Because these suggestions require a more complex coding process and reduce the readability of the Code, developers can only see the actual running effect, it is independent of measuring whether these costs are worth to improve the performance of their ASP applications.
This article is divided into two parts. I will introduce some performance testing results to help developers determine whether a specific action is not only worthwhile for future projects, and can update the original project. In the first part, I will review some basic issues of ASP development. In the second part, some optimal ADO functions are involved, and their results are compared with the ASP page that calls the vb com object to execute the same ADO function. These results are eye-catching and sometimes surprising.
In this article, we will answer the following questions:
* What is the most effective way to write ASP-generated content to the response stream?
* Should I enable the buffer?
* Should I add comments to ASP code?
* Should I explicitly set the default language for the page?
* Should I disable the session status if not required?
* Should I place the script logic in the subprograms and function areas?
* What is the impact of using include files?
* What kind of load will be applied during error handling?
* Does setting a context processing affect the performance?
All tests are conducted using Microsoft's wast, a free tool that can be found here. I created a simple test script using wast and repeatedly called the ASP page test described below (more than 70,000 times each ). The response time is based on the average total time of the last byte (TTLB), that is, the time from the initial request time to the time when the tool receives the last bit of data from the server. Our test Server is a Pentium 166, with a memory of 196 MB, a client of Pentium 450, and a memory of 256 MB. You may think that the performance of these machines is not very advanced, but do not forget that we do not want to test the server capacity, we just want to test the time the server spends processing a page each time. During the test, these machines do not do any other work. Wast test scripts, test reports, and all ASP test pages are included in the ZIP file. You can review and test them on your own.
What is the most effective way to write ASP-generated content to the response stream?
One of the main reasons for using ASP is to generate dynamic content on the server. Obviously, the starting point of our test is to determine the most suitable method for sending dynamic content to the response stream. Among the multiple options, two are the most basic: one is to use the inline ASP tag, and the other is to use the response. Write statement.
To test these options, we created a simple ASP page with some variables defined and their values inserted into the table. Although this page is not very simple and practical, it allows us to separate and test some separate problems.
Use ASP inline flag
The first test involves marking with Inline ASP <% = x %>, where X is a variable with a value assigned. So far, this method is the easiest to execute, and it keeps the HTML part of the page in a format that is easy to read and maintain.
<% Option explicit
Dim firstname
Dim lastname
Dim middleinitial
Dim address
Dim City
Dim state
Dim phonenumber
Dim faxnumber
Dim email
Dim Birthdate
Firstname = "John"
Middleinitial = "Q"
Lastname = "public"
Address = "100 Main Street"
City = "New York"
State = "NY"
Phonenumber = "1-212-555-1234"
Faxnumber = "1-212-555-1234"
Email = "john@public.com"
Birthdate = "1/1/1950"
%>
<HTML>
<Head>
<Title> response test </title>
</Head>
<Body>
<H1> response test <Table>
<Tr> <TD> <B> First name: </B> </TD> <% = firstname %> </TD> </tr>
<Tr> <TD> <B> middle initial: </B> </TD> <% = middleinitial %> </TD> </tr>
<Tr> <TD> <B> last name: </B> </TD> <% = lastname %> </TD> </tr>
<Tr> <TD> <B> address: </B> </TD> <% = address %> </TD> </tr>
<Tr> <TD> <B> City: </B> </TD> <% = city %> </TD> </tr>
<Tr> <TD> <B> state: </B> </TD> <% = State %> </TD> </tr>
<Tr> <TD> <B> phone number: </B> </TD> <% = phonenumber %> </TD> </tr>
<Tr> <TD> <B> Fax number: </B> </TD> <% = faxnumber %> </TD> </tr>
<Tr> <TD> <B> Email: </B> </TD> <% = Email %> </TD> </tr>
<Tr> <TD> <B> Birth date: </B> </TD> <% = birthdate %> </TD> </tr>
</Table>
</Body>
</Html>
/App1/response1.asp complete code
Previous best (response speed) = 8.28 msec/Page
Use the response. Write statement in each line of HTML
We recommend that you avoid using the previous method in many good learning documents. The main reason is that when the response time is applied to the output page and the processing page, if the web server has to convert between sending pure HTML and processing scripts, it is called context conversion. When most programmers hear this, their first response is to wrap every line of the original HTML in the response. Write function.
...
Response. Write ("<HTML> ")
Response. Write ("Response. Write ("<title> response test </title> ")
Response. Write ("Response. Write ("<body> ")
Response. Write ("Response. Write ("<Table> ")
Response. write ("<tr> <TD> <B> First name: </B> </TD> <TD> "& firstname &" </TD> </tr> ")
Response. write ("<tr> <TD> <B> middle initial: </B> </TD> <TD> "& middleinitial &" </TD> </tr> ")
... <
/App1/response2.asp Fragment
Previous best (response speed) = 8.28 msec/Page
Response time = 8.08 msec/Page
Difference =-0.20 msec (reduced by 2.4%)
We can see that using this method has a very low performance benefit compared to using the inline Tag Method, probably because the page loads a lot of small function calls to the server. The biggest disadvantage of this method is that because HTML is embedded in scripts, the script code becomes longer and harder to read and maintain.
Use the packaging function
When we try to use the response. Write statement, the most frustrating result is that the response. Write function cannot place a CRLF at the end of each line. Therefore, when you read the source code from the browser, the HTML that was originally well arranged is now a line that is not finished. I think your next discovery may be even more frightening: There is no sister function writeln in the response object. Therefore, an obvious response is to create a packaging function for the response. Write function to attach a CRLF to each row.
...
Writecr ("<tr> <TD> <B> First name: </B> </TD> <TD> "& firstname &" </TD> </tr> ")
...
Sub writecr (STR)
Response. Write (STR & vbcrlf)
End sub
/App1/response4.asp Fragment
Previous best (response speed) = 8.08 msec/Page
Response time = 10.11 msec/Page
Difference = + 2.03 msec (increased by 25.1%)
Of course, because this method effectively doubles the number of function calls, its impact on performance is also obvious, so you have to avoid it at any cost. It is ironic that CRLF also adds two bytes to each row in the response stream, which the browser does not need to render to the page. What HTML formatting does is to make it easier for your competitors to read your HTML source code and understand your design.
Connect consecutive response. Write to a separate statement.
The next logical step without considering the tests we conducted with the packaging function is to separate the response. the Write statement extracts all the strings and connects them to a separate statement. This reduces the number of function calls and greatly improves the page performance.
...
Response. Write ("<HTML> "&_
"<Head> "&_
"<Title> response test </title> "&_
"</Head> "&_
"<Body> "&_
"<H1> response test "<Table> "&_
"<Tr> <TD> <B> First name: </B> </TD> <TD>" & firstname & "</TD> </tr> "&_
...
"<Tr> <TD> <B> Birth date: </B> </TD> <TD>" & birthdate & "</TD> </tr> "&_
"</Table> "&_
"</Body> "&_
"</Html> ")
/App1/response3.asp Fragment
Previous best (response speed) = 8.08 msec/Page
Response time = 7.05 msec/Page
Difference =-1.03 msec (reduced by 12.7%)
Currently, this is the optimal configuration.
Connect consecutive response. Write to a separate statement, and add a CRLF at the end of each line
Considering those who require their source code to look purely in the browser, I used the vbcrlf constant to insert some carriage returns at the end of each line in the previous test, and then re-run it.
...
Response. Write ("<HTML>" & vbcrlf &_
"<Head>" & vbcrlf &_
"<Title> response test </title>" & vbcrlf &_
"</Head>" & vbcrlf &_
...
/App1/response5.asp Fragment
The previous best (response speed) = 7.05 msec/Page
Response time = 7.63 msec/Page
Difference = + 0.58 msec (increased by 8.5%)
The running results have a slight reduction in performance, probably due to additional concatenation and increased character volumes.
Review and observation
Some rules can be drawn from the previous test on ASP output:
* Avoid excessive use of inline ASP.
* The continuous response. Write statement is always connected into a separate statement.
* Never use the wrap function to append CRLF around response. Write.
* If HTML output must be formatted, add CRLF directly to the response. Write statement.
Should I enable the buffer?
Start the buffer through the script program
If response. Buffer = true is included at the top of the ASP script, IIS will cache the page content.
<% Option explicit
Response. Buffer = true
Dim firstname
...
/App1/buffer _ 1. asp Fragment
Previous best (Response Time) = 7.05 msec/Page
Response time = 6.08 msec/Page
Difference =-0.97 msec (down by 13.7%)
The performance has been greatly improved. But wait, there will be better.
Enable the buffer through Server Configuration
Although the buffer is started by default in IIS 5.0, you must manually start it in IIS 4.0. In this case, find the Properties dialog box of the site, where you can select the configuration button from the Home Directory label. Select enable buffering under "app options ". For this test, the response. Buffer statement is removed from the script.
Previous best = 7.05 msec/Page
Response time = 5.57 msec/Page
Difference =-1.48 msec (down by 21.0%)
At present, this is the fastest response we have ever achieved, which is 21% lower than the response time in our best case. From now on, we will take the response time as the benchmark value for future tests.
Review and observation
The buffer is 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 cannot properly run the buffer, you only need the response. Buffer = false command. One disadvantage of the buffer is that the user cannot see anything from the server before the entire page is processed. Therefore, it is a good idea to call response. Flush to update users occasionally during complex page processing.
Now we add another rule: Enable the buffer always through the server settings.
Should I add comments to ASP code?
Most HTML developers know that it is not a good idea to include HTML comments. First, they will increase the size of data transmission. Second, they will only provide other developers with information about your page organization. But what about the notes on the ASP page? They never leave the server, but they do need to increase the size of the page, so they must be decomposed using ASP.
In this test, we added 20 comments, each of which has 80 characters and a total of 1600 characters.
<% Option explicit
'-------------------------------------------------------------------------------
... 20 lines...
'-------------------------------------------------------------------------------
Dim firstname
...
/App2/comment_1.asp Fragment
Benchmark = 5.57 msec/Page
Response time = 5.58 msec/Page
Difference = + 0.01 msec (increased by 0.1%)
The test results are amazing. Although annotations are almost twice the size of the file itself, their existence does not significantly affect the response time. Therefore, we can follow the following rules:
As long as the usage is moderate, ASP comments have little or no impact on performance.
Should I explicitly set the default language for the page?
IIS uses VBScript as the default setting. However, in most cases, the <% @ Language = VBScript %> declaration is used to explicitly set the language to VBScript. Our next test will verify the impact of this statement on performance.
<% @ Language = VBScript %>
<% Option explicit
Dim firstname
...
/App2/language1.asp fragment.
Reference value = 5.57 msec/Page
Response time = 5.64 msec/Page
Difference = + 0.07 msec (increased by 1.2%)
We can see that the statement containing the language has a slight impact on the performance. Therefore:
* Set the default language configuration of the server to match the language used on the site.
* Do not set language declaration unless you use a non-default language.
Should I disable the session status if not required?
There are many reasons to avoid using the Session Context of IIS, which can already be an article independently. The question we are trying to answer now is whether to disable the session context when the page is not needed to improve performance. In theory, it should be certain, because in this way, the page does not need to demonstrate the session context.
Like a buffer, the session status can be configured through a script or a server.
Disable session context using scripts
For this test, to disable the session context on the page, I add a session state declaration.
<% @ Enablesessionstate = false %>
<% Option explicit
Dim firstname
...
/App2/session_1.asp fragment.
Reference value = 5.57 msec/Page
Response time = 5.46 msec/Page
Difference =-0.11 msec (down by 2.0%)
Through such a small effort, we have made great progress. Now let's take a look at the second part.
Disable session context through Server Configuration
To disable the session context on the server, go to the properties dialog box of the site. Select the configuration button on the Home Directory tab. Then, cancel the "enable session state" option under "app options. We run the test without the enablesessionstate declaration.
Reference value = 5.57 msec/Page
Response time = 5.14 msec/Page
Difference =-0.43 msec (down by 7.7%)
This is another significant improvement in performance. Therefore, our rule should be: when not needed, the session state is always closed at the page or application level.
Does option explicit actually change the performance?
Set option explicit at the top of an ASP page to require all variables to be declared on the page before use. There are two reasons for this. First, the application can process variable access more quickly. Second, this prevents accidental use of variable names. In this test, we removed the option explicit reference and the dim Declaration of the variable.
Reference value = 5.57 msec/Page
Response time = 6.12 msec/Page
Difference = + 0.55 msec (9.8% increase ),
Although some code lines are removed from the page, the response time is increased. So although option explicit sometimes takes time, it has a significant performance. Therefore, we can add another rule: Option explicit is always used in VBScript.
Should script logic be placed in subprograms and function areas?
Using Functions and subprograms to organize and manage code is a good method, especially when a code area is used multiple times on the page. The disadvantage is to add an additional function call to the system for the same work. Another problem with subroutines and functions is the scope of variables. Theoretically, specifying variables in a function area is more effective. Now let's take a look at how these two aspects work.
Move the response. Write statement into the subroutine
This test only moves the response. Write statement into a child program zone.
...
Call writetable ()
Sub writetable ()
Response. Write ("<HTML> "&_
"<Head> "&_
...
"<Tr> <TD> <B> Email: </B> </TD> <TD>" & Email & "</TD> </tr> "&_
"<Tr> <TD> <B> Birth date: </B> </TD> <TD>" & birthdate & "</TD> </tr> "&_
"</Table> "&_
"</Body> "&_
"</Html> ")
End sub
/App2/function1.asp Fragment
Reference value = 5.57 msec/Page
Response time = 6.02 msec/Page
Difference = + 0.45 msec (8.1% increase)
As expected, subroutine calls impose additional burden on the page.
Move all scripts into subroutines
In this test, both the response. Write statement and the variable Declaration are moved into a sub-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> "&_
"</Head> "&_
"<Body> "&_
"<H1> response test "<Table> "&_
"<Tr> <TD> <B> First name: </B> </TD> <TD>" & firstname & "</TD> </tr> "&_
...
"<Tr> <TD> <B> Birth date: </B> </TD> <TD>" & birthdate & "</TD> </tr> "&_
"</Table> "&_
"</Body> "&_
"</Html> ")
End sub
/App2/function2.asp Fragment
Reference value = 5.57 msec/Page
Response time = 5.22 msec/Page
Difference =-0.35 msec (6.3% lower)
Very interesting! Although the variable is moved to the function range to add additional function calls, it actually improves the performance. We can add the following rules:
* On a page, if the code needs to be used more than once, the code will be enclosed in the function area.
* When appropriate, move the variable declaration to the function range.
What is the impact of using include files?
An important function of ASP programming is to include code from other pages. With this function, programmers can share functions on multiple pages to make the code easier to maintain. The disadvantage is that the server must assemble pages from multiple sources. The following are two tests using the include file.
Include files using Inline code
In this test, a short 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/shortde_1.asp Fragment
Reference value = 5.57 msec/Page
Response time = 5.93 msec/Page
Difference = + 0.36 msec (6.5% increase)
This is not surprising. Use the include file to generate the load.
Use the include file in the function area
The code is encapsulated in a subroutine in an include file. Include references are carried out at the top of the page and subprograms are called at the appropriate position 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
Reference value = 5.57 msec/Page
Response 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 generated during error handling?
For all real applications, error handling is necessary. In this test, the error handle is called by calling the on error resume next function.
<% Option explicit
On Error resume next
Dim firstname
...
/App2/error_1.asp Fragment
Reference value = 5.57 msec/Page
Response time = 5.67 msec/Page
Difference = 0.10 msec (1.8% increase)
As you can see, the error handle brings a price. We can make the following suggestions: the error handle is used only when the test or control capability is exceeded. A basic example is to access other resources, such as the COM Object of the ADO or filesystem object.
Does setting a context processing affect the performance?
When an error occurs, set a context on the page to allow the script to reverse. This is set by using the processing Declaration on the page.
<% @ Transaction = required %>
<% Option explicit
Dim firstname
...
/App2/transact1.asp Fragment
Reference value = 5.57 msec/Page
Response time = 13.39 msec/Page
Difference = + 7.82 msec (140.4% increase)
Ah! This is the real and most dramatic result. Therefore, pay attention to the following rules: the processing context is used only when two or more operations are executed as one unit.
Conclusion
The first part of this article is the accumulation of many small things. To emphasize this problem, I set up the last test, in which we performed all the operations that seem indifferent but actually have a bad impact that we have tested before. I have included many response. Write statements, disabled the buffer, set the default language, removed the option explicit reference, and initialized the error handle.
<% @ Language = VBScript %>
<%
On Error resume next
Firstname = "John"
...
Birthdate = "1/1/1950"
Response. Write ("<HTML> ")
Response. Write ("Response. Write ("<title> response test </title> ")
Response. Write ("Response. Write ("<body> ")
Response. Write ("Response. Write ("<Table> ")
Response. Write ("<tr> <TD> <B> First name: </B> </TD> <TD> "&_
"Firstname &" </TD> </tr> ")
...
Response. Write ("<tr> <TD> <B> Birth date: </B> </TD> <TD> "&_
"Birthdate &" </TD> </tr> ")
Response. Write ("</table> ")
Response. Write ("</body> ")
Response. Write ("%>
/App2/final_1.asp Fragment
Reference value = 5.57 msec/Page
Response time = 8.85 msec/Page
Difference = + 3.28 msec (58.9% increase)
It may sound obvious, but understanding is more important, that is, the code we place on the page will affect the performance. Small changes on the page sometimes greatly increase the response time.
Rule Overview
* Avoid excessive use of inline ASP.
* The continuous response. Write statement is always connected into a separate statement.
* Never use the wrap function around response. Write to append CRLF.
* If HTML output must be formatted, add CRLF directly to the response. Write statement.
* Enable the buffer through server settings.
* As long as the usage is moderate, ASP comments have little or no impact on performance.
* Set the default language configuration of the server to match the language used on the site.
* Do not set language declaration unless you use a non-default language.
* Option explicit is always used in VBScript.
* When not required, the session state is always closed at the page or application level.
* The include file is used only when the code is shared between pages.
* On a page, if the code needs to be used more than once, the code will be enclosed in the function area.
* When appropriate, move the variable declaration to the function range.
* The error handle is used only when the test or control capability is exceeded.
* Context processing is used only when two or more operations are executed as one unit.
Looking back, there are many issues that can serve as a general principle:
* Avoid redundancy-do not set the attributes already set in the default state.
* Limit the number of function calls.
* Narrow down the code scope.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
