ylg娱乐官网哪些才是加强ASP质量的一级选取

是否应该开启缓冲器?

  ASP开发人员为了在他们的设计项目中获得更好的性能和可扩展性而不断努力。幸运地是,有许多书籍和站点在这方面提供了很好的建议。但是这些建议的基础都是从ASP平台工作的结构上所得出的结论,对实际获得的性能的提高没有量的测量。由于这些建议需要更加复杂的编码过程并降低了编码的可读性,开发人员就只能在看不到实际运行效果的情况下,独自衡量为了提高他们ASP应用程序的性能是否值得付出这些代价。 

结论 

本篇教程主要介绍:将ASP生成的内容写入响应流中最有效的方法,即用 Response.Write 和 <%=%> 向客户端输出内容时的效率测试。 

  通过脚本程序启动缓冲器
  在ASP脚本的顶部包含Response.Buffer=True ,IIS就会将页面的内容缓存。 

  本文分为两大部分,我将介绍一些性能测试结果,帮助开发人员来确定某一特定举措是否不仅对将来的项目来说是值得的,并且能够对原来的项目进行更新。在第一部分我将回顾一些ASP开发的基础性问题。在第二部分,将涉及一些最优化ADO函数,并将它们的结果与调用VB COM对象执行相同ADO函数的ASP页面进行比较。这些结果很让人开眼界,甚至有些时候是很令人吃惊的。 

  本文第一部分的重要之处在于许多小事情的累积。为了强调这个问题,我设置了最后一个测试,在其中进行了我们以前曾经测试过的看来无所谓但实际上有坏影响的所有操作。我包含了许多Response.Write 声明、关闭了缓冲器、设置了默认语言、去掉了Option Explicit 引用并初始化了错误句柄。 

  使用ASP的一个最主要原因是在服务器上生成动态内容。所以很明显,我们测试的起点是确定将动态内容发送到响应流中的最适合的方式。 

  < % OPTION EXPLICIT 
  Response.Buffer = true 
  Dim FirstName 
  … 

  在本文中,我们将回答以下问题: 

  < %@ 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 >”) 
  % > 

在多种选择中,有两个是最基本的:一是使用内联ASP标记,另一个是使用Response.Write 语句。 

  /app1/buffer__1.asp的片段 

  * 将ASP生成的内容写入响应流中最有效的方法是什么? 
  * 是否应该开启缓冲器? 
  * 是否应该考虑向ASP代码中增加注释? 
  * 是否应该为页面明确地设置默认语言? 
  * 如果不需要,是否应该关闭Session 状态? 
  * 是否应该把脚本逻辑放在子程序和函数区中? 
  * 使用包含文件有什么影响? 
  * 执行错误处理时会施加什么样的负载? 
  * 设置一个上下文处理是否对性能有影响? 

  /app2/final_1.asp片段 

  为测试这些选择,我们创建了一个简单的ASP页面,其中定义了一些变量,然后将它们的值插入表格中。虽然这个页面很简单也不是很实用 

  以前的最佳(反应时间)= 7.05 msec/page 
  反应时间 = 6.08 msec/page 
  差= -0.97 msec (降低13.7%) 

所有测试都是用Microsoft的Web应用程序重点工具(WAST)来进行的,这是一个免费的工具,可以在这里( 脚本,反复调用下面所描述的ASP页面测试(每个超过70,000次)。反应的时间基于平均最后字节总时间(TTLB), 也就是从最初请求的时间到工具从服务器接收最后一位数据的时间。我们的测试服务器是一个Pentium 166,内存为196MB,客户机为Pentium 450,内存为256MB。你也许会想这些机器的性能并不算很高级,但是不要忘了,我们并不是要测试服务器的容量,我们只是要测试服务器每次处理一个页面所用的时间。测试期间这些机器不做其它工作。WAST 测试脚本、测试报告以及所有的ASP测试页面都包含在ZIP文件( 

  基准值 = 5.57 msec/page 
  反应时间 = 8.85 msec/page 
  差 = +3.28 msec (58.9% 增加) 

,但它允许我们分离并测试一些单独的问题。 

  性能得到了极大提高。但是等等,还能有更好的。 

将ASP生成的内容写入响应流中最有效的方法是什么? 

  听起来可能很明显,但是理解更重要,那就是我们放置在页面上的代码会对性能有影响。页面上的小变化有时会大大地增加反应时间。 

  使用ASP内联标记 

  通过服务器配置启动缓冲器 

  使用ASP的一个最主要原因是在服务器上生成动态内容。所以很明显,我们测试的起点是确定将动态内容发送到响应流中的最适合的方式。在多种选择中,有两个是最基本的:一是使用内联ASP标记,另一个是使用Response.Write 语句。 

规则概括 

  第一个测试包括使用内联ASP标记<%=x%>,其中x是一个已赋值的变量。到目前为止,这个方法是最容易执行的,并且它使页面的HTML部分 

  虽然在IIS 5.0中缓冲器是被默认启动的,但是在IIS 4.0中还必须手动来启动它。这时要找到站点的Properties 对话框,在那里,从Home Directory 标签中选择配置按钮。然后在”App options”下选择”enable buffering” 。对于这个测试,Response.Buffer 语句从脚本中被移走了。 

  为测试这些选择,我们创建了一个简单的ASP页面,其中定义了一些变量,然后将它们的值插入表格中。虽然这个页面很简单也不是很实用,但它允许我们分离并测试一些单独的问题。 

  * 避免内联ASP的过多使用。 
  * 总是将连续Response.Write 语句连接进一个单独语句内。 
  * 永远不要在Response.Write 周围使用包装函数以附加CRLF。 
  * 如果必须格式化HTML输出,直接在Response.Write 语句内附加CRLF。 
  * 总是通过服务器设置开启缓冲器。 
  * 只要使用适度,ASP注释对性能的影响很小或根本没有影响。 
  * 设置服务器的默认语言配置以与站点上使用的语言相匹配。 
  * 除非你使用非默认语言,不要设置语言声明。 
  * 在VBScript中总是使用Option explicit 。 
  * 在不需要的情况下,总是在页面或应用程序的水平上关闭Session状态。 
  * 只有当代码在页面之间共享时才使用Include 文件。 
  * 在一个页面上,如果代码要使用一次以上,就将代码封入函数区。 
  * 适当时候,将变量声明移到函数范围内。 
  * 只有会发生超出测试或控制能力之外的情况时才使用错误句柄。 
  * 只有当两个或更多操作被作为一个单元执行时,才使用上下文处理。 

保持一种易于阅读和维护的格式。 

  以前的最佳= 7.05 msec/page 
  反应时间 = 5.57 msec/page 
  差= -1.48 msec (降低 21.0%) 

  使用ASP内联标记 

  现在回顾一下,有许多问题可以作为普遍性的方针: 

<% 
OPTION EXPLICIT ‘此句作用是强制使用每个变量前必须先定义 

  目前,这是我们所得到的最快反应了,比我们以前最好情况下的反应时间还要降低21%。从现在开始,我们以后的测试都要把这个反应时间作为基准值。 

  第一个测试包括使用内联ASP标记< %= x % >,其中x是一个已赋值的变量。到目前为止,这个方法是最容易执行的,并且它使页面的HTML部分保持一种易于阅读和维护的格式。 

  * 避免冗余–不要设置那些默认状态下已经设置的属性。 
  * 限制函数调用的次数。 
  * 缩小代码的范围。 

Dim FirstName 
Dim LastName 
Dim MiddleInitial 
Dim Address 
Dim City 
Dim State 
Dim PhoneNumber 
Dim FaxNumber 
Dim EMail 
Dim BirthDate 
FirstName = “John” 
MiddleInitial = “Q” 
LastName = “Public” 
Address = “100 Main Street” 
City = “New York” 
State = “NY” 
PhoneNumber = “1-212-555-1234” 
FaxNumber = “1-212-555-1234” 
EMail = “john@public.com” 
BirthDate = “1/1/1950” 
%> 

  回顾及观测 

  < % OPTION EXPLICIT 
  Dim FirstName 
  Dim LastName 
  Dim MiddleInitial 
  Dim Address 
  Dim City 
  Dim State 
  Dim PhoneNumber 
  Dim FaxNumber 
  Dim EMail 
  Dim BirthDate 
  FirstName = “John” 
  MiddleInitial = “Q” 
  LastName = “Public” 
  Address = “100 Main Street” 
  City = “New York” 
  State = “NY” 
  PhoneNumber = “1-212-555-1234” 
  FaxNumber = “1-212-555-1234” 
  EMail = “john@public.com” 
  BirthDate = “1/1/1950” 
  % > 

  在本文的第二部分,我们将探索有关ADO和COM对象一些深入的问题。 

  <HTML> 
  <HEAD> 
  <TITLE>Response Test</TITLE> 
  </HEAD> 
  <BODY> 
  <H1>Response Test</H1> 
  <TABLE> 
  <tr><td><b>First Name:</b></td><td><%=FirstName%></td></tr> 
  <tr><td><b>Middle Initial:</b></td><td><%=MiddleInitial%></td></tr> 
  <tr><td><b>Last Name:</b></td><td><%=LastName%></td></tr> 
  <tr><td><b>Address:</b></td><td><%=Address%></td></tr> 
  <tr><td><b>City:</b></td><td><%=City%></td></tr> 
  <tr><td><b>State:</b></td><td><%=State%></td></tr> 
  <tr><td><b>Phone Number:</b></td><td><%=PhoneNumber%></td></tr> 
  <tr><td><b>Fax Number:</b></td><td><%=FaxNumber%></td></tr> 
  <tr><td><b>EMail:</b ></td><td><%=EMail%></td></tr> 
  <tr><td><b>Birth Date:</b></td><td><%=BirthDate%></td></tr> 
  </TABLE> 
  </BODY> 
  </HTML> 

  缓冲器是提高性能的好方法,所以把缓冲器设置成服务器的默认值很有必要。如果因为某些原因,页面不能正确地使缓冲器运行,只需要Response.Buffer=False 命令即可。缓冲器的一个缺点是在整个页面处理完之前,用户从服务器看不到任何东西。因此,在复杂页面的处理期间,偶而调用一次Response.Flush 来更新用户是个好主意。 

  < HTML > 
  < HEAD > 
  < TITLE >Response Test< / TITLE > 
  < /HEAD > 
  < BODY > 
  < H1 >Response Test< /H1 > 
  < TABLE > 
  < tr >< td >< b >First Name:< /b >< /td >< td >< %= FirstName % >< /td >< /tr > 
  < tr >< td >< b >Middle Initial:< /b >< /td >< td >< %= MiddleInitial % >< /td >< /tr > 
  < tr >< td >< b >Last Name:< /b >< /td >< td >< %= LastName % >< /td >< /tr > 
  < tr >< td >< b >Address:< /b >< /td >< td >< %= Address % >< /td >< /tr > 
  < tr >< td >< b >City:< /b >< /td >< td >< %= City % >< /td >< /tr > 
  < tr >< td >< b >State:< /b >< /td >< td >< %= State % >< /td >< /tr > 
  < tr >< td >< b >Phone Number:< /b >< /td >< td >< %= PhoneNumber % >< /td >< /tr > 
  < tr >< td >< b >Fax Number:< /b >< /td >< td >< %= FaxNumber % >< /td >< /tr > 
  < tr >< td >< b >EMail:< /b >< /td >< td >< %= EMail % >< /td >< /tr > 
  < tr >< td >< b >Birth Date:< /b >< /td >< td >< %= BirthDate % >< /td >< /tr > 
  < /TABLE > 
  < /BODY > 
  < /HTML > 

  >>>>>未完待续<<<<<  

  /app1/response1.asp的完整代码 

  现在在我们的规则中又增加了一条:总是通过服务器设置开启缓冲器。 

  /app1/response1.asp的完整代码 

  以前的最佳(反应速度) = 8.28 msec/page 

是否应该考虑向ASP代码中增加注释? 

  以前的最佳(反应速度) = 8.28 msec/page 

  在HTML的每一行使用Response.Write 语句 

  大部分HTML开发人员都知道包含HTML注释不是个好主意,首先会增加传输数据的规模,其次它们只是向别的开发人员提供有关你页面组织的信息。但是ASP页面上的注释又如何呢?它们从来不离开服务器,但也确实要增加页面的规模,因此必须用ASP进行分解。 

  在HTML的每一行使用Response.Write 语句 

  许多比较好的学习文档建议避免使用前面的那种方法。其主要理由是,在输出页面和处理页面施加反应时间的过程中,如果web 服务器不 

  在这次的测试中,我们增加20条注释,每条有80个字符,总共有1600个字符。 

  许多比较好的学习文档建议避免使用前面的那种方法。其主要理由是,在输出页面和处理页面施加反应时间的过程中,如果web 服务器不得不在发送纯HTML和处理脚本之间进行转换,就会发生一种被称为上下文转换的问题。大部分程序员一听到这里,他们的第一反应就是将原始的HTML的每一行都包装在Response.Write函数中。 

得不在发送纯HTML和处理脚本之间进行转换,就会发生一种被称为上下文转换的问题。大部分程序员一听到这里,他们的第一反应就是将原始 

  < % OPTION EXPLICIT 
  ’——————————————————————————- 
  … 20 lines … 
  ’——————————————————————————- 
   Dim FirstName 
   … 

  … 
  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 >Middle Initial:< /b >< /td >< td >” & MiddleInitial & “< 
/td >< /tr >”) 
  … 

的HTML的每一行都包装在Response.Write函数中。 

  /app2/comment_1.asp片段 

  /app1/response2.asp的片段 

  … 

  基准= 5.57 msec/page 
  反应时间= 5.58 msec/page 
  差 = +0.01 msec (增加 0.1%) 

  以前的最佳(反应速度) = 8.28 msec/page 
  反应时间 = 8.08 msec/page 
  差= -0.20 msec (减少 2.4%) 

  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>Middle Initial:</b></td><td>” & MiddleInitial & “/td ></tr>”) 

  测试的结果是惊人的。虽然注释几乎相当于文件本身的两倍,但是它们的存在并没有给反应时间带来很大的影响。所以说我们可以遵循以下规则: 

  我们可以看到,使用这种方法与使用内联标记的方法相比在性能上获得的收益非常小,这也许是因为页面给服务器装载了一大堆小的函数调用。这种方法最大的缺点是,由于现在HTML都嵌入脚本中,所以脚本代码变得更加冗长,更加难以阅读和维护。 

  … 

  只要使用适度,ASP注释对性能的影响很小或根本没有影响。 

  使用包装函数 

  /app1/response2.asp的片段 

是否应该为页面明确地设置默认语言? 

  当我们试图使用Response.Write 语句这种方法时,最令人灰心的发现可能就是Response.Write 函数不能在每行的结尾处放置一个CRLF 。因此,当你从浏览器中阅读源代码时,本来布置得非常好的HTML,现在成了没有结束的一行。我想,你的下一个发现可能会更令你恐怖:在Response 对象中没有其姊妹函数Writeln 。所以,一个很明显的反应就是为Response.Write 函数创建一个包装函数,以便给每一行都附加一个CRLF 。 

  以前的最佳(反应速度) = 8.28 msec/page 

发表评论

电子邮件地址不会被公开。 必填项已用*标注