Performance Author: Green Apple Studio compilation
ASP developers continue to work to achieve better performance and scalability in their design projects. Fortunately, there are many books and sites that offer good advice in this regard. However, these recommendations are based on the structure of the ASP platform to draw conclusions, the actual performance of the improvement is not measured. Because these recommendations require a more complex coding process and reduce the readability of the code, developers can only measure the cost of improving the performance of their ASP applications alone, without seeing the actual effect.
This article is divided into two parts, and I'll introduce some performance test results to help developers determine whether a particular initiative is not only worthwhile for future projects, but can also update the original project. In the first part I will review some of the fundamental issues of ASP development. In the second section, we will cover some of the most optimized ADO functions and compare their results with ASP pages that invoke the same ADO function as the VB COM object. These results are eye-opening, and sometimes surprising.
In this article, we will answer the following questions:
* What is the most efficient way to write ASP-generated content to the response stream?
* Should the buffer be turned on?
* Should you consider adding comments to your ASP code?
* Should you explicitly set the default language for the page?
* Should the session state be closed if not required?
* Should the scripting logic be placed in subroutines and function areas?
* What is the effect of using the Include file?
* What kind of load will be imposed when performing error handling?
* Does setting a context handle have an impact on performance?
All tests are done with Microsoft's Web Application Focus tool (WAST), a free tool that can be found here. I used wast to create a simple test script that repeatedly calls the ASP page tests described below (each more than 70,000 times). The response time is based on the average last byte total time (TTLB), which is the time from the initial request to the tool receiving the last data from the server. Our test server is a Pentium 166, the memory is 196MB, the client is Pentium 450, the memory is 256MB. You may think that these machines are not very advanced in performance, but don't forget that we are not testing the capacity of the server, we just want to test the time it takes for the server to work on one page at a time. These machines do not do other work during the test. WAST test scripts, test reports, and all ASP test pages are included in the zip file, which you can review and test yourself.
What is the most effective way to write ASP-generated content to the response stream?
One of the most important reasons for using ASP is to generate dynamic content on the server. So obviously, the starting point of our testing is to determine the most appropriate way to send dynamic content to the response stream. Of the many choices, two are most basic: one is using inline ASP tags and the other is using Response.Write statements.
To test these choices, we created a simple ASP page that defines the variables and then inserts their values into the table. Although this page is very simple and not very practical, it allows us to isolate and test some separate issues.
Using ASP inline markup
The first test includes the use of inline ASP tags <%= x, where x is an assigned variable. So far, this method is easiest to perform, 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 = "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 >
< BODY >
< H1 >response test
< TABLE >
< TR >< TD >< B >first name:</></td >< TD ><%= FirstName% ></td >&L T /tr >
< TR >< TD >< B >middle initial:</></td >< TD ><%= middleinitial% ></t D ></tr >
< TR >< TD >< B >last name:</></td >< TD ><%= LastName% ></td >< /tr >
< TR >< TD >< B >Address:</b ></td >< TD ><%= address% ></td ></t R >
< TR >< TD >< B >City:</b ></td >< TD ><%= City% ></td ></tr >
< TR >< TD >< B >State:</b ></td >< TD ><%= State% ></td ></tr &G T
< TR >< TD >< B >phone number:</></td >< TD ><%= phonenumber% ></td &G t;</tr >
< TR >< TD >< B >fax number:</></td >< TD ><%= faxnumber% ></td >&L T /tr >
< TR >< TD >< B >EMail:</b ></td >< TD ><%= EMail% ></td ></tr &G T
< TR >< TD >< B >birth date:</></td >< TD ><%= birthdate% ></td >&L T /tr >
</table >
</body >
Complete code for/app1/response1.asp
Previous best (reaction speed) = 8.28 msec/page
Use the Response.Write statement on every line in the HTML
Many of the better learning documents suggest avoiding using the previous approach. The main reason for this is that in the process of applying reaction time to the output page and the processing page, a problem called context conversion occurs if the Web server has to convert between sending pure HTML and processing scripts. When most programmers hear this, their first reaction is to wrap each line of the original HTML in the Response.Write function.
...
Response.Write ("< HTML >")
Response.Write ("< head >")
Response.Write ("< title >response test</title >")
Response.Write ("
Response.Write (&
