ASP优化:几招提高ASP性能的最佳选择(3)_ASP教程
推荐:马克斯电影站生成Rss Feed的代码前段时间为了给本人的电影站增加Rss订阅功能,动手写了个动态生成Rss Feed的ASP代码,没法上传附件,就直接贴代码吧,反正也不长,用马克斯做电影站的朋友直接拿去用吧,其它类型的站点修改一下
回顾及观测
缓冲器是提高性能的好方法,所以把缓冲器设置成服务器的默认值很有必要。如果因为某些原因,页面不能正确地使缓冲器运行,只需要Response.Buffer=False 命令即可。缓冲器的一个缺点是在整个页面处理完之前,用户从服务器看不到任何东西。因此,在复杂页面的处理期间,偶而调用一次 Response.Flush 来更新用户是个好主意。
现在在我们的规则中又增加了一条:总是通过服务器设置开启缓冲器。
是否应该考虑向ASP代码中增加注释?
大部分HTML开发人员都知道包含HTML注释不是个好主意,首先会增加传输数据的规模,其次它们只是向别的开发人员提供有关你页面组织的信息。但是ASP页面上的注释又如何呢?它们从来不离开服务器,但也确实要增加页面的规模,因此必须用ASP进行分解。
在这次的测试中,我们增加20条注释,每条有80个字符,总共有1600个字符。
<% OPTION EXPLICIT /app2/comment |
基准= 5.57 msec/page
反应时间= 5.58 msec/page
差 = 0.01 msec (增加 0.1%)
测试的结果是惊人的。虽然注释几乎相当于文件本身的两倍,但是它们的存在并没有给反应时间带来很大的影响。所以说我们可以遵循以下规则:
只要使用适度,ASP注释对性能的影响很小或根本没有影响。
是否应该为页面明确地设置默认语言?
IIS处理VBScript是默认的设置,但是我看到,在大多数例子中还是用<%@LANGUAGE=VBSCRIPT%>声明将语言明确地设置为VBScript 。我们的下一个测试将检验这个声明的存在对性能有什么影响。
<%@ LANGUAGE=VBSCRIPT %> <% OPTION EXPLICIT Dim FirstName … |
/app2/language1.asp片段。
基准值= 5.57 msec/page
反应时间= 5.64 msec/page
差= 0.07 msec (增加1.2%)
可以看到,包含了语言的声明对性能有一个轻微的影响。因此:
* 设置服务器的默认语言配置以与站点上使用的语言相匹配。
* 除非你使用非默认语言,不要设置语言声明。
如果不需要,是否应该关闭Session 状态?
避免使用IIS的Session上下文有许多理由,那些已经可以独立成为一篇文章。我们现在试图回答的问题是当页面不需要时,关闭Session上下文是否对性能提高有所帮助。从理论上讲应该是肯定的,因为这样一来就不需要用页面例示Session上下文了。
同缓冲器一样,Session状态也有两种配置方法:通过脚本和通过服务器设置。
通过脚本关闭Session上下文
对于这个测试,要关闭页面中的Session上下文,我增加一个Session状态声明。
<%@ ENABLESESSIONSTATE = FALSE %> <% OPTION EXPLICIT Dim FirstName … |
/app2/session_1.asp片段。
基准值= 5.57 msec/page
反应时间= 5.46 msec/page
差= -0.11 msec (降低2.0%)
只通过这样一个小小的努力就得到了不错的进步。现在看看第二部分。
通过服务器配置关闭Session 上下文
要在服务器上关闭Session 上下文,请到站点的Properties 对话框。在Home Directory 标签上选择Configuration 按钮。然后在"App options"下取消"enable session state" 的选择。我们在没有ENABLESESSIONSTATE 声明的情况下运行测试。
基准值 = 5.57 msec/page
反应时间= 5.14 msec/page
差= -0.43 msec (降低7.7%)
这是性能的又一个显著提高。所以,我们的规则应是:在不需要的情况下,总是在页面或应用程序的水平上关闭Session状态。
使用Option Explicit 会使性能有实质改变吗?
在一个ASP页面的顶部设置Option Explicit 以要求所有的变量在使用之前都要在页面上进行声明。这有两个原因。首先应用程序可以更快地处理变量的存取。其次,这样可以防止我们无意中错用变量的名字。在这个测试中我们移走Option Explicit 引用和变量的Dim 声明。
基准值 = 5.57 msec/page
反应时间= 6.12 msec/page
差 = 0.55 msec (9.8% 增加)、
尽管有一些代码行从页面中去掉了,反应时间却依然增加了。所以尽管使用Option explicit 有时候费时间,但是在性能上却有很显著的效果。因此我们又可以增加一条规则:在VBScript中总是使用Option explicit。
是否应该把脚本逻辑放在子程序和函数区?
用函数和子程序来组织和管理代码是一个很好的方法,特别是当一个代码区在页面中多次使用的情况。缺点是要在系统上增加一个做相同工作的额外函数调用。子程序和函数的另一个问题是变量的范围。从理论上说,在一个函数区内指定变量更有效。现在我们看看这两个方面如何发生作用。
将Response.Write 语句移入子程序
这个测试只是将Response.Write 语句移入一个子程序区内。
… CALL writeTable() SUB writeTable() Response.Write("<html>" & _ "<head>" & _ … "<tr><td><b>EMail:</b></td><td>" & EMail & "</td></tr>" & _ "<tr><td><b>Birth Date:</b></td><td>" & BirthDate & "</td></tr>" & _ "</table>" & _ "</body>" & _ "</html>") END SUB |
/app2/function1.asp片段
基准值= 5.57 msec/page
反应时间= 6.02 msec/page
差 = 0.45 msec (8.1% 增加)
同预料中一样,子程序调用给页面带来了额外的负担。
将所有脚本移入子程序中
在这个测试中,Response.write 语句与变量声明都移入一个子程序区中。
<% OPTION EXPLICIT |
/app2/function2.asp片段
基准值= 5.57 msec/page
反应时间= 5.22 msec/page
差 = -0.35 msec (6.3% 降低)
非常有趣!尽管将变量移到函数范围内增加了额外的函数调用,但实际上却提高了性能。我们又可以增加以下规则:
* 在一个页面上,如果代码要使用一次以上,就将代码封入函数区。 分享:ASP 编程中20个非常有用的例子(一)1、如何用Asp判断你的网站的虚拟物理路径
答:使用Mappath方法:< %= Server.MapPath("")% >
2、我如何知道使用者所用的浏览器?
答:使用the Request object方法:
* 适当时候,将变量声明移到函数范围内。
- 相关链接:
- 教程说明:
ASP教程-ASP优化:几招提高ASP性能的最佳选择(3)。