Skills
tip 16: Use response.isclientconnected before you start a long task
If the user loses patience, they can discard the ASP page before they start executing their request. If they click Refresh or jump to another page on the server, there will be a new request at the end of the ASP request queue and a disconnected request in the middle of the queue. This usually happens when the server is in a high load (it has a long request queue and the corresponding response time is very long), which can only make the situation worse. If the user is no longer connected, the point of the ASP page is not executed (especially the Low-speed, heavyweight ASP pages). You can use the Response.IsClientConnected property to check this situation. If it returns FALSE, it should call Response.End and discard the remaining content of the page. In fact, whenever an ASP executes a new request, IIS 5.0 encodes the method to check how long the request in the queue is. If there is more than 3 seconds, the ASP checks to see if the customer is still connected and ends the request immediately if the customer is disconnected. You can use the AspQueueConnectionTestTime setting in metabase to adjust the timeout time for these 3 seconds.
If a page has been executed for a long time, you may also want to check response.isclientconnected at certain intervals. After you enable response buffering, it is a good idea to perform response.flush at a certain time interval, telling the user what is going on.
Note in IIS 4.0, response.isclientconnected will not function unless Response.Write is first executed. If buffering is enabled, you also need to perform response.flush. This is not necessary in IIS 5.0-response.isclientconnected works very well. In any case, response.isclientconnected has some overhead, so it is only used before the operation is performed at least 500 milliseconds (if you want to maintain the throughput of dozens of pages per second, which is a long time). As a general rule, do not call it in every iteration of a tight loop, for example, when a row in a table is drawn, it may be called once every 20 or 50 lines.
Tip 17: Instantiate objects with <OBJECT> tags
If you need to refer to objects that cannot be used in all code paths, especially those of the server-or application-scope, use the <object runat=server id=objname> tag in Global.asa to declare them instead of using Ser Ver. CreateObject method. Server.CreateObject immediately creates the object. If you don't use that object later, don't waste resources. The <object id=objname> tag declares objname, but in practice objname is not created at this time until its method or property is first used.
This is another example of lazy computing.
tip 18: TypeLib declarations using ADO objects and other components
When using ADO, developers often include adovbs.txt to gain access to different constants of ADO. The file must be included in each page that you want to use these constants. The constant file is very large and adds a lot of compilation time and script size overhead to each ASP page.
IIS 5.0 provides the ability to bind to a component type library. Allows you to reference a type library and use it on each ASP page. There is no need to pay a price for compiling constant files per page, and component developers do not have to generate VBScript #include files for use in ASP.
To access the ADO type library, put one of the following statements into 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: Leverage your browser's ability to authenticate
Popular browsers have advanced support for the following features, such as XML, DHTML, Java applets, and remote Data services. Try to take advantage of these features. All of these technologies can reduce the round-trip to and from the WEB server by performing client-side validation and data caching. If you are running a smart browser, the browser can perform some validation for you (for example, check the credit card's checksum for validity before running POST). Once again, please try to use these features. By reducing the round-trip to the server, the pressure on the Web server is reduced and network traffic is reduced (although the initial page sent to the browser may be larger), all the backend resources accessed by the server are reduced. And users do not have to often extract new pages, so that users feel better. This does not mitigate the need for server-side validation. Server-side validation should also be done frequently. This prevents bad data from the client for some reason, such as hackers, or browsers that do not run client verifier.
Many sites consist of HTML created independently of the browser. This often hinders developers from using popular browser features that improve performance. For truly high-performance sites that must care for browsers, a good strategy is to optimize your pages for popular browsers. Using the browser performance component in ASP, it is easy to detect the capabilities of the browser. Tools such as Microsoft FrontPage can help you design code that uses the desired target browser and HTML version. For a more detailed discussion, see when Better worse? Weighing the Technology trade-offs (English).
tip 20: Avoid string concatenation in loops
Many people create strings like this in a loop:
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 with this approach. First, the time spent repeating the connection string increases at a rate of two square curves; roughly calculated, the time it takes to run the loop is proportional to the number of records multiplied by the square of the number of fields. A simple example would give a clear indication of this.
s = ""
For i = ASC ("A") to ASC ("Z")
s = S & Chr (i)
Next
In the first iteration, get the string "a" of a character. In the second iteration, VBScript must reassign the string and copy the two-character "AB" to S. In the third iteration, it must reassign s again, and copy three characters to S. In the nth (26) iterations, it must reassign and copy n characters to S. Is 1+2+3+...+n's and, for N (n+1)/2-time replication.
In the example of the recordset above, if there are 100 records and 5 fields, the internal loop executes 100*5 = 500 times, and the time taken to complete all the replication and reallocation will be proportional to 500*500 = 250,000. For a properly sized recordset, there will be many copies.
In this example, the code can improve: The string connection will be Response.Write () or inline script (<% = fld. Value%>) instead. If you turn on response buffering, this operation will be quick, because Response.Write only adds data to the end of the response buffer. is no longer reassigned and therefore very effective.
Especially when you are converting an ADO recordset to an HTML table, consider using either GetRows or GetString.
If you are using a JScript connection string, it is strongly recommended to use the + = operator, which is to use s + = "A string" instead of S = S + "a string".
