(Author: Green Apple studio compilation, 2000 at 17:20 on November 10) should turn on whether the buffer? Boot Buffer Boot Buffers in the ASP script contains response.buffer = true, IIS caches the contents of the page. <% OPTION Explicit Response.Buffer = True Dim Firstname ... /App1/buffer__1.Ana's segment previous (reaction time) = 7.05 msec / PAGE reaction time = 6.08 msec / PAGE difference = -0.97 msec (13.7%) Performance has been greatly improved. But wait, it can be better. Configure the startup buffer through the server Although the buffer in IIS 5.0 is started by default, it must also be manually started in IIS 4.0. At this time, you should find the Properties dialog of the site, where, select the configuration button from the Home Directory tab. Then select "Enable Buffering" under "App Options". For this test, the Response.buffer statement is removed from the script. Previous best = 7.05 msec / page reaction time = 5.57 msec / page difference = -1.48 msec (decrease 21.0%) Currently, this is the fastest response we have gotten, better than we used to be the best case. To reduce 21%. From now on, we will test this reaction time as a reference value. Review and observation buffer are a good way to improve performance, so it is necessary to set the buffer to the server. If some reason, the page does not correctly run the buffer, only the response.buffer = false command can be required. One disadvantage of the buffer is that the user can't see anything from the server before processing the entire page. Therefore, during the processing of complex pages, even if the response.flush to update the user is a good idea. Now there is an additional one in our rules: Always set the buffer through the server. Should I consider adding comments to the ASP code? Most HTML developers know that HTML comments are not a good idea, first increase the size of the transferred data, followed by providing information about the information about your page organizations to other developers. But what is the comment on the ASP page? They never leave the server, but it is also necessary to increase the size of the page, so you must decompose with ASP. In this test, we increase 20 annotations, with 80 characters each, a total of 1600 characters. <% OPTION Explicit '--------------------------------------------- ---------------------------------- ... 20 lines ... '----------- -------------------------------------------------- ------------------ DIM FIRSTNAME ... /APP2/Comment_1.asp fragment reference = 5.57 msec / PAGE reaction time = 5.58 msec / page difference = 0.01 msec (add 0.1% The result of the test is amazing. Although notes are almost twice that of the document itself, their existence does not have a big impact on the reaction time.
So we can follow the following rules: As long as the mode is moderate, the ASP annotation has little effect on performance or no effect. Should you explicitly set the default language for the page? IIS Processing VBScript is the default setting, but I see that in most examples or <% @Language = VBScript%> declaration to explicitly set the language to VBScript. Our next test will test the presence of this statement impact on performance. <% @ Language = vbscript%> <% Option Explicit Dim Firstname ... /app2/language1.asp fragment. Benchmark = 5.57 msec / page reaction time = 5.64 msec / page difference = 0.07 msec (increasing 1.2%) It can be seen that there is a slight impact on performance. Therefore: * Set the default language configuration of the server to match the language used on the site. * Do not set language statements unless you use non-default languages. If you don't need it, should I close the Sems status? Avoid using IIS's session contexts have many reasons, those already able to be an article independently. The problem we try to answer now is that when the page does not need, close the session context is helpful. In theory, it should be affirmed, because this will not need to use the page to exempt the session context. Like the buffer, there are two configuration methods: through scripts and through server settings. Close the SESSION context through the script For this test, you want to close the session context in the page, I add a session status declaration. <% @ EnablesessionState = false%> <% option explicit dimfriese_1.asp fragment. Benchmark = 5.57 msec / page reaction time = 5.46 msec / page difference = -0.11 msec (2.0%) is a good progress only by such a small effort. Now look at the second part. Close the Session context through the server configuration To close the session context on the server, go to the Properties dialog of the site. Select the Configuration button on the Home Directory tab. Then, "Enable Session State" is then canceled under "App Options". We run test without EnablesessionState declaration. Benchmark = 5.57 msec / page reaction time = 5.14 msec / page difference = -0.43 msec (reduced 7.7%) This is another significant improvement in performance. So, our rules should be: Close the SESSION state at the level of the page or application is always in the case of unnecessary. Will the performance have substantive changes in the performance of Option Explicit? Set Option Explicit at the top of an ASP page to require all variables to be declared on the page before use. There are two reasons. First, the application can handle the access to the variable faster. Second, this can prevent the name of our unintentional use of variables. In this test we remove the DIM declaration of Option Explicit references and variables.
Benchmark = 5.57 msec / page reaction time = 6.12 msec / page difference = 0.55 msec (9.8% increase), although some code lines have been removed from the page, the reaction time is still increased. So, although the Option Explicit is sometimes time, it has a significant effect on performance. So we can add a rule: Option Explicit is always used in VBScript. Will the script logic in a subroutine and a function area? To organize and manage code with functions and subroutines is a good method, especially when a code area is used multiple times in the page. The disadvantage is to add an additional function call to the same work on the system. Another problem with the subroutine and function is the range of variables. Theoretically, the specified variable is more effective in a function area. Now let's take a look at how these two areas. Mushing the Response.write statement into the subroutine This test is just in one subroutine area. ... Call WriteTable () Sub WriteTable () Response.write ("" & _ "
" & _ ... "<% Option Explicit Call WriteTable () Sub WriteTable () Dim FirstName ... Dim Birthdate firstname = "john" ... birthdate = "1/1/1950" Response.write ("" & _ "
& _