结论
本文第一部分的重要之处在于许多小事情的累积。为了强调这个问题,我设置了最后一个测试,在其中进行了我们以前曾经测试过的看来无所谓但实际上有坏影响的所有操作。我包含了许多Response.Write 声明、关闭了缓冲器、设置了默认语言、去掉了Option Explicit 引用并初始化了错误句柄。
< %@ LANGUAGE=VBSCRIPT % >
< %
On Error Resume Next
FirstName = "John"
…
BirthDate = "1/1/1950"
Response.Write("< html >")
Response.Write("< head >")
Response.Write(" < title >Response Test< /title >")
Response.Write("< /head >")
Response.Write("< body >")
Response.Write("< h1 >Response Test< /h1 >")
Response.Write("< table >")
Response.Write("< tr >< td >< b >First Name:< /b >< /td >< td >" &_
"FirstName & "< /td >< /tr >")
…
Response.Write("< tr >< td >< b >Birth Date:< /b >< /td >< td >" &_
" BirthDate & "< /td >< /tr >")
Response.Write("< /table >")
Response.Write("< /body >")
Response.Write("< /html >")
% >
/app2/final_1.asp片段
基准值 = 5.57 msec/page
反应时间 = 8.85 msec/page
差 = +3.28 msec (58.9% 增加)
听起来可能很明显,但是理解更重要,那就是我们放置在页面上的代码会对性能有影响。页面上的小变化有时会大大地增加反应时间。
规则概括
* 避免内联ASP的过多使用。
* 总是将连续Response.Write 语句连接进一个单独语句内。
* 永远不要在Response.Write 周围使用包装函数以附加CRLF。
* 如果必须
格式化HTML输出,直接在Response.Write 语句内附加CRLF。
* 总是通过服务器设置开启缓冲器。