| Tip 21: Enable browser and proxy caching By default, ASP disables caching in browsers and agents. This will make sense, because ASPs are inherently dynamic and potentially time-sensitive information. If you have a page that does not need to be refreshed every time you view it, you should enable the browser and proxy caching. This allows the browser and the agent to use a cached copy of a page for a certain period of time, which can be controlled in length. Caching can significantly reduce the server load, so that users feel better. What kind of dynamic pages can be cached? An example is provided: Weather page, updated every 5 minutes. List the homepage of the news or the homepage of the press release, updated 2 times a day. Public fund operations list, basic statistics updated 1 times a few hours. Note that with a browser or proxy cache, only a few hits are logged to the WEB server. If you want to accurately measure all the pages to view or post ads, you may not like using the browser and proxy caching. The browser cache is controlled by the HTTP deadline heading that the WEB server sends to the browser. ASP provides two mechanisms for sending headers. To set the page to expire after a certain number of minutes in the future, set the Response.Expires property. The following example notifies the browser that the content expires after 10 minutes: <% Response.Expires =%> Setting Response.Expires to negative or 0 disables caching. Be sure to use a larger negative number, such as 1000 (greater than one day), to overcome the difference between the server clock and the browser clock. The second property, Response.ExpiresAbsolute, allows you to set a specified time when content expires: <% Response.ExpiresAbsolute = #May 31,2001 13:30:15#%> If you do not want to use the Response object to set an expiration date, you can write the <META> tag to HTML, usually written in <HEAD> within the HTML file. Some browsers will respond to this instruction, but the agent will not. <meta http-equiv= "Expires" value= "may 31,2001 13:30:15" > Finally, you can identify whether content is valid for the HTTP proxy cache, using the Response.CacheControl property. Set the property to "public" to allow the proxy to cache content. <% Response.CacheControl = "Public"%> By default, this property is set to Private. Note that proxy caching should not be enabled for pages that display private data for a user, because the proxy may be serving a user page belonging to another user. tip 22: Use Server.Transfer instead of Response.Redirect whenever possible Response.Redirect notifies the browser to request a different page. This function is often used to redirect users to the login or error page. Since redirection forces a new page request, the browser must make a round trip to the Web server two times, and the Web server must handle additional requests. IIS 5.0 introduces a new function, Server.Transfer, that performs different ASP pages that are delivered to the same server. This eliminates the extra round-trip from the browser to the WEB server, which improves overall system performance while improving response times to users. See the new direction in redirection (English), which discusses Server.Transfer and Server.Execute. You can also view a complete list of new features for IIS 5.0 and ASP 3.0 in leveraging ASP in IIS 5.0. English Tip 23: Add a slash at the end of the directory URL The trick is to set the trailing slash (/) of the URL to the directory. If the slash is omitted, the browser will make a request to the server and only notify it is looking for a directory. The browser then makes a second request, adds a slash at the end of the URL, and the server responds with the default document for that directory or, if there is no default document and directory browsing is enabled, in the directory list. Adding a slash eliminates the first useless round-trip. For the sake of user friendliness, you may want to omit the slash at the end of the displayed name. For example, write: <a href= "http://msdn.microsoft.com/workshop/" title= MSDN Web Workshop ">http://msdn.microsoft.com/workshop</a> It also applies to URLs that point to the home page of the Web site: please use the following: <a href= "http://msdn.microsoft.com/", do not use <a href= "http://msdn.microsoft.com" ". Tip 24: Avoid using server variables Accessing the server variable will cause the Web site to make a special request to the server, and then collect all the server variables, not just the one you need. It's like retrieving a particular piece of information from a folder in a moldy attic. When you want a piece of information, you must go to the attic to get the folder before accessing the information. This is the same as when the server variable is requested for performance access when the server variable is requested for the first time. Subsequent access to other server variables does not cause performance access. Never access unqualified request objects (for example, request ("Data"). For items that are not in Request.Cookies, Request.Form, Request.QueryString, or request.clientcertificate, there is a pair of request.servervariables The implied invocation. Request.ServerVariables collections are much slower than other collections. Tip 25: Upgrade to the latest and best version System components are often upgraded and are recommended for upgrading to the latest and best versions. It is best to upgrade to Windows 2000 (also, IIS 5.0, ADO 2.5, MSXML 2.5, Internet Explorer 5.0, VBScript 5.1, and JScript 5.1). IIS 5.0 and ADO 2.5 achieve very good performance on multiprocessor computers. Under Windows 2000, an ASP can scale well to four processors or more, but it cannot be expanded to more than two processors in IIS 4.0,asp. The more scripts and ADO you use in your application, the greater the performance you will get after you upgrade to Windows 2000. If you are unable to upgrade to Windows 2000, you can upgrade to the latest version of SQL Server, ADO, VBScript, and JScript, MSXML, Internet Explorer, and NT 4 Service packs. They both improve performance and enhance reliability. Tip 26: Adjust your WEB server There are many IIS tuning parameters that can improve site performance. For example, using IIS 4.0, we often find that increasing ASP's ProcessorThreadMax parameters (see IIS documentation) can be very beneficial, especially if you are often waiting for back-end resources such as databases or other middle-tier products, such as Screen-scrapers, 's site. In IIS 5.0, it may be found that opening the ASP Thread gating a competition map is more efficient for AspProcessorThreadMax to find an optimal setting. The following tuning of IIS (English) is a good piece of information. The best configuration depends on (among other factors) the application code, the hardware running on it, and the client's workload. The only way to find the best setup is to run the performance test, which takes us into the next tip. Tip 27: Perform a performance test As mentioned above, performance is an indicator. If you are trying to improve the performance of your site, set performance goals first and then improve performance until you reach your goal. Do not put all of your performance tests at the end of your project. Often at the end of the project, it is too late to make the architectural changes that are not available and disappoint the customer. Performance testing is part of daily testing. Performance testing can be done on a stand-alone component, such as an ASP page or COM object, or you can take a site as a whole. Many people use a single browser request page to test the performance of their Web site. This will give you a good sense of how your site responds, but you don't know anything about the performance of your site under load. Typically, you need a dedicated test environment to accurately measure performance. This environment should be those, in the processor speed, number of processors, memory, hard disk, network configuration, etc., can simulate the hardware components of the product hardware. Then, you need to define the workload of the client: how many concurrent users they have, how often they make the request, the type of page they will access, and so on. If you cannot get actual usage data from a site, you need to estimate them. Finally, you need a tool that simulates the expected client workload. With the help of these tools, you can start answering questions such as how many servers do I need if I have N concurrent users? You can also identify bottlenecks and optimize the goals. Some good Web strength test tools are listed below. The Microsoft Web application Strength Test (WAS) toolkit is highly recommended. was allowed to record test scripts and then simulate hundreds or thousands of users accessing the WEB server. was reported a large number of statistical results, including the number of requests per second, the distribution of response time, and error counts. Was has an enhanced client and web-based interface; The Web interface allows remote testing. Be sure to read the IIS 5.0 Debugging Guide (English). |
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
