Program | Performance Tip 11: Using response buffering
By opening "Response buffering" You can buffer an entire page content that is worth outputting, which minimizes the amount of data output to the browser, thereby improving overall performance. Each output consumes a lot, so the less you write, the better the effect. TCP/IP is more efficient at sending a small number of large packets than sending large numbers of packets, because it is slow to start and send continuously.
There are 2 ways to open response buffering. First, you can use Internet Services Manager to open response buffering for the entire application, which is the recommended way, and in IIS4.0 and IIS5.0, the response buffering is turned on by default. Second, on each page, you can put the following code on the head to open response buffering:
<% Response.Buffer = True% >
This code must be executed before any data is exported to the browser (that is, before any HTML content is displayed and before any cookies are set). In general, it is a good solution to open response buffering for the entire application, so that you do not have to set the code as above on each page header.
A common problem with opening response buffering is that the user must wait for the entire page to be fully produced before they can see the content. For a long running page, you can set the Response.buffer=false off buffer. Then, a good strategy is to take advantage of the Response.Flush method, which will output all HTML content that has been described by ASP to the browser. For example, after describing the 100 rows of a 1,000-row table, the ASP can use Response.Flush to force output of the 100 rows to the browser, where the user can see the first 100 rows of data, while the rest of the row data is ready to be generated.
Note that in the case of the above 1,000-Line table output, for some browsers, they will not output any contents of the table unless they encounter a </table > tag. If so, you can split the table into many tables that contain a small number of rows, and then invoke the Response.Flush output after each table is generated. The new version of Internet Explorer is not displayed until the entire table is downloaded, and if the column width of the table is defined, the table will be generated in a very fast speed.
Another problem with opening response buffering is that very large server memory is consumed when very large pages are generated.
Tip 12: Batch-line scripts and Response.Write commands
VBScript Syntax <% = expression% > means the value of the output expression. If response buffering is not open, each such statement will output data to the browser in the form of many small packets, which will degrade program performance. Therefore, use the following tips: Replace multiple lines of expression next to each other as a call and output with a Response.Write name. For example, in the following example, there is only one write for the output of each field in each row:
<table>
<% for each fld in Rs. Fields%>
<th><% = fld. Name%></th>
<%
Next
While not Rs. Eof
%>
<tr>
<% for each fld in Rs. Fields%>
<td><% = fld. Value%></td>
<% Next
</tr>
<% Rs. MoveNext
Wend%>
</table>
Here is more efficient code, one output per line:
<table>
<%
For each fld in Rs. Fields
Response.Write ("<th>" & fld. Name & "</th>" & VbCrLf)
Next
While not Rs. Eof
Response.Write ("<tr>")
For each fld in Rs. Fields%>
Response.Write ("<td>" & fld. Value & "</td>" & VbCrLf)
Next
Response.Write "</tr>"
Wend
%>
</table>
This technique is very useful when the response buffering is closed. It is best to open response buffering so that you can see how the batch Response.wwrite improves program performance.
Tip 13: Reference objects with < OBJECT > tags
If you need to reference objects other than the code path (especially the server, application-scoped objects), use the in the Global.asa file
< object Runat=server Id=objname > tags to define them instead of using the Server.CreateObject method. You can use the Server.CreateObject method to create an object immediately so that if you do not use it later, you waste resources. Use
The < object Id=objname > tag can define an object objname, but objname is not actually created until its properties or methods are used for the first time.
Tip 14: Avoid concatenating strings in loops
Many people create a string in a loop, just like the following:
s = "<table>" & VbCrLf
For each fld in Rs. Fields
s = S & "<th>" & fld. Name & "</th>"
Next
While not Rs. Eof
s = S & vbCrLf & "<tr>"
For each fld in Rs. Fields
s = S & "<td>" & fld. Value & "</td>"
Next
s = S & "</tr>"
Rs. MoveNext
Wend
s = S & vbCrLf & "</table>" & VbCrLf
Response.Write S
There are several problems. The first is that the repeated connection string consumes two times, and the time of the run is also the sum of the number of fields calculated. The following simple example illustrates this more clearly:
s = ""
For i = ASC ("A") to ASC ("Z")
s = S & Chr (i)
Next
In the 1th-tier loop, when the value of S is "a"; the 2nd-tier loop, VBScript will reassign the string, copying 2 characters ("AB") into S, and the 3rd-tier loop, which needs to be reassigned and copied 3 characters into S. In the N-tier loop, you need to reassign and copy n characters to S. That is the sum of the 1+2+3+...+n, i.e. n (n+1)/2 copies.
In the above recordset example, if there are 100 records and 5 fields, the internal loop executes 100*5=500 times, and the time to complete all copies and reassignment tasks will be close to 500*500=250,000. This is also the copy work for an appropriate size recordset.
In this example, you can connect to a Response.Write () or inline script (<% =FLD) by replacing a string. Value% >) improves program performance. If the response buffering is open (and should also be turned on), this will be quick because the Response.Write only appends the data to the end of the buffer and does not need to be reassigned.
If you are using a JScript connection string, it is strongly recommended to use the "+ +" operator, that is, to use the s+= "string" instead of S = s+ "string".
Tip 15: Open the browser and proxy buffers
By default, the ASP disables browser and proxy buffering capabilities. If you have a page that you don't want to update every time, you should open the browser and the proxy buffer, which will allow the browser and the agent to use the page's "buffered" copy of the data for a while. Buffering can greatly reduce the amount of data reprinted by the server and improve the browsing performance of the users.
Which categories of dynamic pages fit to be cached? Here are some examples:
Weather page, updated every 5 minutes
News or version list page, updated 2 times per day
Note: When you use a browser or proxy cache, the number of clicks on the Web server is reduced. If you want to get an accurate picture of all the pages, or for mailing ads, it is not appropriate to use the browser and proxy caching.
The browser cache is controlled by the HTTP "Expires" header parameter, which is sent to the browser by the Web server. ASP provides 2 simple ways to send this header parameter. You can use the Response.Expires property to set the page to expire within a certain period of time. The following example tells the browser that the content expires in 10 minutes:
<% Response.Expires =% >
If you set Response.Expires to negative or 0, caching is disabled. The setting for the 2nd attribute, Response.ExpiresAbsolute, allows you to specify that the content expires when a particular time arrives.
<% Response.ExpiresAbsolute = #May 31,2001 13:30:15#% >
In addition to using the response object to set expiration times, you can also write < META > tags in the header of an HTML file. Although the agent
