Skills | Performance 19: Using 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 &? *lt;/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 repeat the string, and more generally, the time it takes to run the loop statement is proportional to the square of the number of records multiplied by the number of fields. You should consider using GetRows or GetString in specific cases where you convert an ADO recordset to an HTML table. If you are concatenating strings in JScript, it is particularly recommended to use the + = operator, that is, to use S + + to use a string instead of S = S +? A string?.
Tip 21: Enable browser and proxy caching
By default, ASP prohibits caching in browsers and proxies. This is meaningful because, in essence, the ASP page is dynamic, with potential information changing over time. If the page does not require a refresh on each view, you should enable the browser and the proxy cache. This allows browsers and agents to use a "cached" copy of the page within a certain amount of time, and you can control the length of time. Caching can greatly reduce the load on the server and shorten the user's waiting time.
What kind of dynamic page can be used as a page to cache?
Note that the number of accesses recorded on the WEB server is reduced when using a browser or proxy cache. If you want to accurately measure all page views or post postings, you do not want to use the browser and proxy caching. The browser cache is controlled by the HTTP "expired" header, which is sent to the browser by the WEB server. ASP provides two simple mechanisms for sending this header. To set the page to expire after a few minutes, set the Response.Expires property.
Tip 22: Use Server.Transfer instead of Response.Redirect whenever possible
Response.Redirect let the browser request another page. This function is often used to redirect the user to a login Response.Redirect to ask the browser to request another page. This function is often used to redirect users to a login or error page. Because redirection forces a new page to be requested, the result is that the browser must travel two times to the Web server, and the Web server must handle one more request. IIS 5.0 introduces a new function Server.Transfer that transfers execution to another ASP page on the same server. This avoids the extra browser-web-the server, which improves overall system performance and shortens user response times. Check the "New direction" in redirect, which should be Server.Transfer and Server.Execute.
Tip 23: Use the back slash in the directory URL
A related trick is to make sure that the backslash (/) is used in the URL that points to the directory. If you omit the backslash, the browser makes a request to the server, just to tell the server that it is requesting the directory. The browser issues a second request, which appends the slash to the URL, after which the server can respond with the default document or directory list for that directory (if there is no default document and directory browsing enabled). Additional slashes will save the first and useless live returns. To make it easier for users to read, you can omit the back slash in the display name.
Tip 24: Avoid using server variables
Accessing a server variable causes the WEB site to send a special request to the server and collect all the server variables, not just the one you requested. This is similar to looking up a file in a moldy attic, in a folder. When you want to find the file, you must go to the attic and find the folder before you can find the file. When you want to find the file, you must go to the attic and find the folder before you can find the file. When you request a server variable, the same happens-the first time you request a server variable, the performance is affected. Subsequent requests for other server variables do not have an impact on performance. Never access an unqualified request object (for example, request ("Data"). For items that are not in Request.Cookies, Request.Form, Request.QueryString, or request.clientcertificate, an implicit invocation of the Request.ServerVariables. The Request.ServerVariables collection is much slower than the other collections.
Tip 25: Upgrade to the latest and most outstanding
System components are constant and we recommend that you upgrade them to the latest and best configurations. It is best to upgrade to Windows 2000 (therefore, you should also upgrade to IIS 5.0, ADO 2.5, MSXML 2.5, Internet Explorer 5.0, VBScript 5.1, and JScript 5.1). On multiprocessor computers, implementing IIS 5.0 and ADO 2.5 can significantly improve performance. Under Windows 2000, ASPs can scale well to four processors or more, while in IIS 4.0 the ASP cannot be extended beyond two processors. The more scripting code and ADO you use in your application, the more performance improves after you upgrade to Windows 2000. If you are not currently able to upgrade to Windows 2000, you can upgrade to the latest versions of SQL Server, ADO, VBScript, and JScript, MSXML, Internet Explorer, and NT 4 Service packs. Both of these can improve performance and reliability.
Tip 26: Optimize your WEB server
There are several IIS tuning parameters that can improve site performance. For example, for IIS 4.0, we often find that adding ASP ProcessorThreadMax parameters (see IIS documentation) can significantly improve performance, especially on sites that tend to wait for back-end resources, such as databases, or other intermediate products, such as screen brushes. In IIS 5.0, you may find it more efficient to enable ASP Thread gating than to find a aspprocessorthreadmax optimal setting, which is now well known.
The best configuration settings depend on (some of these factors) the application code, the system hardware that is running, and the client workload. The only way to find the best setup is to perform a performance test.
Tip 27: Perform a performance test
As we have said before, performance is a feature. If you want to improve the performance of your site, set a performance goal and then step through it until you reach your goal. No, no performance tests are performed. Usually, it's too late to make the necessary structural adjustments at the end of the project, and your customers will be disappointed. Perform the performance test as part of your daily test. You can perform performance tests on individual components, such as for ASP pages or COM objects, or for a site as a whole. Many people use a single browser request page to test the performance of a Web site. Doing so will give you a sense that the site is responding well, but doing so does not actually tell you what the site is doing under the load.
In general, to test performance accurately, you need a dedicated test environment. This environment should include hardware similar to the hardware in the production environment, such as processor speed, processor count, memory, disk, network configuration, and so on. Second, you must specify the workload of the client: how many simultaneous users, how often they send the request, the type of page they click, and so on. If you do not have the actual site usage data, you must estimate the use of the situation. Finally, you need a tool that can simulate the expected client workload. With these tools, you can start answering questions like "How many servers do I need if I have N simultaneous users?" "Sort of thing. You can also identify the causes of bottlenecks and optimize them for this purpose.
(Web page Editor: Wing of the Wind)
