Skills | Performance Skills 15: Batch process inline scripts and Response.Write statements
Tip 16: If the page takes a long time to complete, use response.isclientconnected before executing
Tip 17: Use <OBJECT> tag to sample objects
Tip 18: Use TypeLib binding for ADO and other components
Tip 19: Use the browser's validation capabilities
Tip 20: Avoid using string concatenation in circular statements
Tip 21: Enable browser and proxy caching
Tip 15: Batch inline scripts and Response.Write statements
VBScript syntax <% = Expression%> writes the value of "expression" to the ASP output stream. If the response buffer is not enabled, executing each of these statements will write the data to the browser over the network with many small packets. This is a slow pace. and interspersed with small amounts of script and HTML will cause a switch between script engine and HTML, which can degrade performance. So, the trick is to use the Response.Write call instead of a tightly bound inline expression. For example, in the following example, each field in each row has a write operation on the response stream, and there are many transitions between VBScript and HTML in each line:
<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>
The following code is more efficient, and each row has a write operation on the response stream. All the code is contained within a VBScript block:
<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 particularly effective when response buffering is disabled. It is a good idea to enable response buffering and see if batch Response.Write helps improve performance.
(In this particular example, a nested loop of the table body is established (while not Rs.) EOF ...) You can use carefully constructed GetString to replace. ）
Tip 16: If the page takes a long time to complete, use response.isclientconnected before executing
If the user is impatient, they may discard the ASP page before you start executing their request. If they click Refresh or move to another page on the server, a new request waits at the end of the ASP request queue, and there is a disconnected request in the middle of the queue. This often happens when the server is heavily loaded (so the request queue is long and the response time is correspondingly longer), which can only make the situation worse. Executing an ASP page (especially a slow, large ASP page) does not make sense if the user is no longer connected. You can use the Response.IsClientConnected property to check the situation. If it returns FALSE, it should call Response.End and discard the rest of the page. In fact, IIS 5.0 has programmed this practice to check how long the request has been waiting in the queue whenever the ASP is about to execute a new request. If you have waited there for more than 3 seconds, the ASP checks to see if the client is still connected and terminates the request immediately if there is no connection. You can use the AspQueueConnectionTestTime setting in the metabase to adjust the timeout period from 3 seconds to other values.
If the page takes a long time to complete, you can also check response.isclientconnected from time to times. When response buffering is enabled, it is best to perform response.flush from time to moment to the user to know what is happening.
Note on IIS 4.0, response.isclientconnected does not function unless Response.Write is executed first. If buffering is enabled, you must also perform response.flush. On IIS 5.0, there is no need to do so-response.isclientconnected is working properly. In any case, response.isclientconnected will have some overhead, so it is only necessary to spend at least one operation (say) 500 milliseconds (if you want to maintain the throughput of dozens of pages per second, which is a long time) to use it. Experience shows that you don't call it every time you repeat a tight loop, such as displaying many rows of a table-it might be appropriate to call once every 20 or 50 rows.
Tip 17: Use <OBJECT> tag to sample objects
If you want to refer to objects that are not used in all code paths, especially objects in the server or application scope, declare them using the <object runat=server id=objname> tag in Global.asa instead of Server.CreateObject method. Server.CreateObject can create objects immediately. If you don't use the object later, you're wasting resources. The <object id=objname> tag declares objname, but the objname is not created until its method or property is used for the first time.
This is also an example of lazy computing.
Tip 18: Use TypeLib declarations for ADO and other components
When using ADO, developers often join Adovbs.txt to access the various constants of ADO. You must include this file in each page where you want to use a constant. This constant file is quite large, adding a lot of overhead to the compile time and script size for each ASP page.
IIS 5.0 introduces the ability to bind to a component type library. This allows you to refer to the type library once and use it on each ASP page. Each page does not incur the overhead of compiling a constant file, and component developers do not have to establish vbscript#_include files for use on ASP.
To access the ADO TypeLib, place one of the following statements in the Global.asa.
<!--METADATA name=? Microsoft ActiveX Data Objects 2.5 Library?
Type=? TypeLib? Uuid=? {00000205-0000-0010-8000-00AA006D2EA4}? -->
Or
<!--METADATA type=? TypeLib?
File=? C:\Program Files\Common Files\system\ado\msado15.dll? -->
Tip 19: Use the browser's validation capabilities
Today's browsers provide support for advanced features such as XML, DHTML, Java applets, and remote Data services. Use these features whenever possible. All of these technologies can perform client-side validation and data caching, eliminating round-trip to the WEB server. If you are running a smart browser, the browser can do some validation for you (for example, check the credit card checksum for validity before performing the POST). Use this functionality whenever possible. Reducing the round-trip between the client and server reduces the load on the WEB server and reduces network traffic (although the first page sent to the browser may be larger) and any back-end resources that the server accesses. In addition, users do not have to read new pages as often as they do, so the user feels better. Doing so does not mean that you can not perform server-side validation-you should also always perform server-side validation. This prevents the client from generating the wrong data for some reason, such as a hacker, or the browser does not run a client-side validation routine.
People have done a lot of work to develop "browser-independent" HTML. Because of this concern, developers are reluctant to use popular browser features, but these features could have improved performance. For some truly high-performance sites, you must be concerned about the browser "access" problem, a good strategy is to optimize the page to adapt to the popular browser. Browser functionality can be easily detected in ASP using the browser feature component. Tools such as Microsoft FrontPage help you design code that is appropriate for browsers and for the specified HTML version. See when Better worse? Weighing the Technology trade-offs to understand further discussion.
Tip 20: Avoid using string concatenation in circular statements
Many people create a string in a loop statement, as follows:
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 some problems with this approach. The first problem is that it takes two of times to repeatedly concatenate strings, more commonly
