提高ASP性能的最佳选择(三)

性能

作者:青苹果工作室编译 

结论
  本文第一部分的重要之处在于许多小事情的累积。为了强调这个问题,我设置了最后一个测试,在其中进行了我们以前曾经测试过的看来无所谓但实际上有坏影响的所有操作。我包含了许多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。

  * 总是通过服务器设置开启缓冲器。

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

  * 设置服务器的默认语言配置以与站点上使用的语言相匹配。

  * 除非你使用非默认语言,不要设置语言声明。

  * 在VBScript中总是使用Option explicit 。

  * 在不需要的情况下,总是在页面或应用程序的水平上关闭Session状态。

  * 只有当代码在页面之间共享时才使用Include 文件。

  * 在一个页面上,如果代码要使用一次以上,就将代码封入函数区。

  * 适当时候,将变量声明移到函数范围内。

  * 只有会发生超出测试或控制能力之外的情况时才使用错误句柄。

  * 只有当两个或更多操作被作为一个单元执行时,才使用上下文处理。

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

  * 避免冗余--不要设置那些默认状态下已经设置的属性。

  * 限制函数调用的次数。

  * 缩小代码的范围。

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

时间: 2024-10-29 18:43:34

提高ASP性能的最佳选择(三)的相关文章

提高ASP性能的最佳选择2

性能 是否应该开启缓冲器? 通过脚本程序启动缓冲器 在ASP脚本的顶部包含Response.Buffer=True ,IIS就会将页面的内容缓存. < % OPTION EXPLICIT Response.Buffer = true Dim FirstName - /app1/buffer__1.asp的片段 以前的最佳(反应时间)= 7.05 msec/page 反应时间 = 6.08 msec/page 差= -0.97 msec (降低13.7%) 性能得到了极大提高.但是等等,还能有更好

什么才是提高ASP性能的最佳选择(二)

性能 是否应该开启缓冲器? 通过脚本程序启动缓冲器 在ASP脚本的顶部包含Response.Buffer=True ,IIS就会将页面的内容缓存. < % OPTION EXPLICIT Response.Buffer = true Dim FirstName - /app1/buffer__1.asp的片段 以前的最佳(反应时间)= 7.05 msec/page 反应时间 = 6.08 msec/page 差= -0.97 msec (降低13.7%) 性能得到了极大提高.但是等等,还能有更好

什么才是提高ASP性能的最佳选择

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

什么才是提高ASP性能的最佳选择(续三)

性能 引用记录集中域值的最有效方法是什么? 到目前为止,我都是用名字引用记录集中的域值的.这可能是一种效率很低的方法,因为每次调用都需要查找域.为了证明这一点,下面的测试就要通过记录集中域的集合的指针来引用域(ADO__08.asp): 'write data Do While Not objRS.EOF Response.Write( _ "< TR >" & _ "< TD >" & objRS(0) & &quo

什么才是提高ASP性能的最佳选择(三)

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

提高ASP性能的最佳选择

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

提高ASP性能的最佳选择(二)

性能 作者:青苹果工作室编译 是否应该开启缓冲器? 通过脚本程序启动缓冲器 在ASP脚本的顶部包含Response.Buffer=True ,IIS就会将页面的内容缓存. < % OPTION EXPLICIT Response.Buffer = true Dim FirstName - /app1/buffer__1.asp的片段 以前的最佳(反应时间)= 7.05 msec/page 反应时间 = 6.08 msec/page 差= -0.97 msec (降低13.7%) 性能得到了极大提

提高ASP性能的最佳选择(一)

性能 作者:青苹果工作室编译 ASP开发人员为了在他们的设计项目中获得更好的性能和可扩展性而不断努力.幸运地是,有许多书籍和站点在这方面提供了很好的建议.但是这些建议的基础都是从ASP平台工作的结构上所得出的结论,对实际获得的性能的提高没有量的测量.由于这些建议需要更加复杂的编码过程并降低了编码的可读性,开发人员就只能在看不到实际运行效果的情况下,独自衡量为了提高他们ASP应用程序的性能是否值得付出这些代价. 本文分为两大部分,我将介绍一些性能测试结果,帮助开发人员来确定某一特定举措是否不仅对将

什么才是提高ASP性能的最佳选择(一)

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