Should it turn on the buffer? Start the buffer through the script program
The top of the ASP script contains response.buffer = true, IIS caches the contents of the page.
<% OPTION Explicit
Response.buffer = TRUE
DIM FIRSTNAME
...
/App1/buffer__1.asp fragment
Previous best (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.
Start buffer by server configuration
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, more than 21% of the reaction time we have before. From now on, we will test this reaction time as a reference value.
Review and observation
The buffer is 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
Benchmark = 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 modeled, the ASP annotation has little effect on performance or does not affect.
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
Response time = 5.64 msec / page
Difference = 0.07 msec (increasing 1.2%)
It can be seen that there is a slight impact on performance in the statement. therefore:
* Set the server's default language configuration 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 script
For this test, you want to close the session context in the page, I add a session status declaration.
<% @ EnablesessionState = false%>
<% OPTION Explicit
DIM FIRSTNAME
...
/App2/session_1.asp fragment.
Benchmark = 5.57 MSEC / PAGE
Reaction time = 5.46 msec / page
Difference = -0.11 msec (2.0%)
Just through such a small effort has been a good progress. 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 increase 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 there are some code lines remove 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.
Move the Response.Write statement into a subroutine
This test just moves the Response.Write statement into a subroutine area.
...
Call WriteTable ()
Sub WriteTable ()
Response.write ("" & _
"
" & _
...
| Email: | "& email &" "
" |
| Birth Date: | " & birthdate & " "
"& _
"& _
"")
End Sub
/App2/function1.asp fragment
Benchmark = 5.57 MSEC / PAGE
Reaction time = 6.02 msec / page
Difference = 0.45 msec (8.1% increase)
As expected, subroutine calls bring additional burden to the page.
Move all scripts into subroutines
In this test, the response.write statement and variable declarations are moved into a subroutine area.
<% OPTION Explicit
Call WriteTable ()
Sub WriteTable ()
DIM FIRSTNAME
...
Dim Birthdate
Firstname = "john"
...
Birthdate = "1/1/1950"
Response.write ("" & _
" " & _
Response Test </ Title> "& _</p>
<p></ Head> "& _</p>
<p>"<Body>" & _</p>
<p><H1> Response Test </ h1> "& _</p>
<p><Table> &_</p>
<p>"<Tr> <TD> <B> First Name: </ b> </ td> <td>" & dimstname & "</ td> </ TR>" & _ ...</p>
<p>"<Tr> <td> <b> Birth Date: </ b> </ td> <td>" & birthdate & "</ td> </ tr>"</p>
<p></ Table> "& _</p>
<p></ Body> "& _</p>
<p>"</ Html>")</p>
<p>End Sub</p>
<p>/App2/function2.asp fragment</p>
<p>Benchmark = 5.57 MSEC / PAGE</p>
<p>Reaction time = 5.22 msec / page</p>
<p>Difference = -0.35 msec (6.3% decrease)</p>
<p>very interesting! Although an additional function call is added to the function range, it is actually improved. We can add the following rules:</p>
<p>* On a page, if the code is used more than one, the code is entered into the function area.</p>
<p>* Move the variable declaration to the function range for appropriate time.</p>
<p>What is the impact of using the included file? An important feature of ASP programming is to include code from other pages. With this feature, the programmer can share a function on multiple pages, making the code easier to maintain. A disadvantage is that the server must assemble the page from multiple sources. The following is two tests using the include file.</p>
<p>Use an Include file using inline code</p>
<p>In this test, a small code is moved to an incrude file:</p>
<p><% OPTION Explicit</p>
<p>DIM FIRSTNAME</p>
<p>...</p>
<p>Dim Birthdate</p>
<p>Firstname = "john"</p>
<p>...</p>
<p>Birthdate = "1/1/1950"</p>
<p>%></p>
<p><! - #nclude file = "inc1.asp" -></p>
<p>/App2/include_1.asp fragment</p>
<p>Benchmark = 5.57 MSEC / PAGE</p>
<p>Reaction time = 5.93 msec / page</p>
<p>Difference = 0.36 msec (6.5% increase)</p>
<p>This is not surprising. The load is formed using the include file.</p>
<p>Use the include file in the function area</p>
<p>Here, the code is wrapped in a subroutine in an Include file. The include reference is performed on the top of the page, and the appropriate position adjustment subroutine at the ASP script.</p>
<p><% OPTION Explicit</p>
<p>DIM FIRSTNAME</p>
<p>...</p>
<p>Dim Birthdate</p>
<p>Firstname = "john"</p>
<p>...</p>
<p>Birthdate = "1/1/1950"</p>
<p>Call WriteTable ()</p>
<p>%></p>
<p><! - #nclude file = "inc2.asp" -></p>
<p>/App2/include_2.asp fragment</p>
<p>Benchmark = 5.57 MSEC / PAGE</p>
<p>Reaction time = 6.08 msec / page</p>
<p>Difference = 0.51 msec (9.2% increase)</p>
<p>This affects the effects of performance than the functions call. So: only use the include file when the code is shared between the page.</p>
<p>How much load is formed when performing error processing? For all real applications, error handling is necessary. In this test, the error handle is called by calling the ON ERROR RESUME NEXT function. <% Option Explicit on Error ResMe Next</p>
<p>DIM FIRSTNAME</p>
<p>...</p>
<p>/app2/error_1.asp fragment</p>
<p>Benchmark = 5.57 MSEC / PAGE</p>
<p>Reaction time = 5.67 msec / page</p>
<p>Difference = 0.10 msec (1.8% increase)</p>
<p>You can see that the error handle brings a price. We can make the following suggestions: The error handle is used only when there is a situation outside the test or control. One of the most basic examples is to use COM objects such as ADO or FileSystem objects.</p>
<p>Set whether a context process has an impact on performance? When the error occurs, set a context handle on the page allows the script to reverse operation. This is set by using the processing declaration on the page.</p>
<p><% @ Transaction = Required%></p>
<p><% OPTION Explicit</p>
<p>DIM FIRSTNAME</p>
<p>...</p>
<p>/app2/transact1.asp fragment</p>
<p>Benchmark = 5.57 MSEC / PAGE</p>
<p>Reaction time = 13.39 msec / page</p>
<p>Difference = 7.82 msec (140.4% increase)</p>
<p>what! This is true and most dramatic. So please pay attention to the following rules: The processing context is used only when two or more operations are performed as a unit. <p></p>
<p><p></p></div><div class="text-center mt-3 text-grey">
转载请注明原文地址:https://www.9cbs.com/read-77627.html</div><div class="plugin d-flex justify-content-center mt-3"></div><hr><div class="row"><div class="col-lg-12 text-muted mt-2"><i class="icon-tags mr-2"></i><span class="badge border border-secondary mr-2"><h2 class="h6 mb-0 small"><a class="text-secondary" href="tag-2.html">9cbs</a></h2></span></div></div></div></div><div class="card card-postlist border-white shadow"><div class="card-body"><div class="card-title"><div class="d-flex justify-content-between"><div><b>New Post</b>(<span class="posts">0</span>)
</div><div></div></div></div><ul class="postlist list-unstyled">
</ul></div></div><div class="d-none threadlist"><input type="checkbox" name="modtid" value="77627" checked /></div></div></div></div></div><footer class="text-muted small bg-dark py-4 mt-3" id="footer"><div class="container"><div class="row"><div class="col">CopyRight © 2020 All Rights Reserved
</div><div class="col text-right">Processed:
<b>0.054</b>, SQL:
<b>9</b></div></div></div></footer><script src="./lang/en-us/lang.js?2.2.0"></script><script src="view/js/jquery.min.js?2.2.0"></script><script src="view/js/popper.min.js?2.2.0"></script><script src="view/js/bootstrap.min.js?2.2.0"></script><script src="view/js/xiuno.js?2.2.0"></script><script src="view/js/bootstrap-plugin.js?2.2.0"></script><script src="view/js/async.min.js?2.2.0"></script><script src="view/js/form.js?2.2.0"></script><script>
var debug = DEBUG = 0;
var url_rewrite_on = 1;
var url_path = './';
var forumarr = {"1":"Tech"};
var fid = 1;
var uid = 0;
var gid = 0;
xn.options.water_image_url = 'view/img/water-small.png';
</script><script src="view/js/wellcms.js?2.2.0"></script><a class="scroll-to-top rounded" href="javascript:void(0);"><i class="icon-angle-up"></i></a><a class="scroll-to-bottom rounded" href="javascript:void(0);" style="display: inline;"><i class="icon-angle-down"></i></a></body></html><script>
var forum_url = 'list-1.html';
var safe_token = '5VU9yfGiOXtlexzDp6ONbqhv1X4pusrU_2BXYyXK9Rhvs09lvoAG6Z69XwwbLWNnb_2FiTB8Xs4aB851ABusPoq4Bw_3D_3D';
var body = $('body');
body.on('submit', '#form', function() {
var jthis = $(this);
var jsubmit = jthis.find('#submit');
jthis.reset();
jsubmit.button('loading');
var postdata = jthis.serializeObject();
$.xpost(jthis.attr('action'), postdata, function(code, message) {
if(code == 0) {
location.reload();
} else {
$.alert(message);
jsubmit.button('reset');
}
});
return false;
});
function resize_image() {
var jmessagelist = $('div.message');
var first_width = jmessagelist.width();
jmessagelist.each(function() {
var jdiv = $(this);
var maxwidth = jdiv.attr('isfirst') ? first_width : jdiv.width();
var jmessage_width = Math.min(jdiv.width(), maxwidth);
jdiv.find('img, embed, iframe, video').each(function() {
var jimg = $(this);
var img_width = this.org_width;
var img_height = this.org_height;
if(!img_width) {
var img_width = jimg.attr('width');
var img_height = jimg.attr('height');
this.org_width = img_width;
this.org_height = img_height;
}
if(img_width > jmessage_width) {
if(this.tagName == 'IMG') {
jimg.width(jmessage_width);
jimg.css('height', 'auto');
jimg.css('cursor', 'pointer');
jimg.on('click', function() {
});
} else {
jimg.width(jmessage_width);
var height = (img_height / img_width) * jimg.width();
jimg.height(height);
}
}
});
});
}
function resize_table() {
$('div.message').each(function() {
var jdiv = $(this);
jdiv.find('table').addClass('table').wrap('<div class="table-responsive"></div>');
});
}
$(function() {
resize_image();
resize_table();
$(window).on('resize', resize_image);
});
var jmessage = $('#message');
jmessage.on('focus', function() {if(jmessage.t) { clearTimeout(jmessage.t); jmessage.t = null; } jmessage.css('height', '6rem'); });
jmessage.on('blur', function() {jmessage.t = setTimeout(function() { jmessage.css('height', '2.5rem');}, 1000); });
$('#nav li[data-active="fid-1"]').addClass('active');
</script> |
