分享
 
 
 

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

王朝asp·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

(作者:青苹果工作室编译2000年11月10日 17:20)

是否应该开启缓冲器?

通过脚本程序启动缓冲器

在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%)

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

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

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

以前的最佳= 7.05 msec/page

反应时间 = 5.57 msec/page

差= -1.48 msec (降低 21.0%)

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

回顾及观测

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

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

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

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

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

< % OPTION EXPLICIT

'-------------------------------------------------------------------------------

… 20 lines …

'-------------------------------------------------------------------------------

Dim FirstName

/app2/comment_1.asp片段

基准= 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

CALL writeTable()

SUB writeTable()

Dim FirstName

Dim BirthDate

FirstName = "John"

BirthDate = "1/1/1950"

Response.Write("< 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 >Birth Date:< /b >< /td >< td >" & BirthDate & "< /td >< /tr >" & _

"< /table >" & _

"< /body >" & _

"< /html >")

END SUB

/app2/function2.asp片段

基准值= 5.57 msec/page

反应时间= 5.22 msec/page

差 = -0.35 msec (6.3% 降低)

非常有趣!尽管将变量移到函数范围内增加了额外的函数调用,但实际上却提高了性能。我们又可以增加以下规则:

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

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

使用包含文件有什么影响?

ASP编程的一个重要功能就是包含来自其它页面的代码。通过这项功能,程序员可以在多个页面上共享函数,使代码更易于维护。缺点在于服务器必须从多个来源组装页面。以下是使用Include文件的两个测试。

使用内联代码的Include 文件

在这个测试中,有一小段代码被移到一个Include 文件中:

< % OPTION EXPLICIT

Dim FirstName

Dim BirthDate

FirstName = "John"

BirthDate = "1/1/1950"

% >

< !-- #include file="inc1.asp" -- >

/app2/include_1.asp片段

基准值 = 5.57 msec/page

反应时间= 5.93 msec/page

差 = +0.36 msec (6.5% 增加)

这不奇怪。使用Include 文件形成了负载。

在函数区使用Include 文件

在这里,代码都包装在一个Include 文件中的子程序里。Include 引用是在页面顶部进行的,在ASP脚本的适当位置调用子程序。

< % OPTION EXPLICIT

Dim FirstName

Dim BirthDate

FirstName = "John"

BirthDate = "1/1/1950"

CALL writeTable()

% >

< !-- #include file="inc2.asp" -- >

/app2/include_2.asp片段

基准值 = 5.57 msec/page

反应时间= 6.08 msec/page

差 =+0.51 msec (9.2% 增加)

这对性能造成的影响比functions调用还大。因此:只有当代码在页面之间共享时才使用Include 文件。

执行错误处理时会形成多大的负载?

对于所有真正的应用程序来说,错误处理都是必要的。这个测试中,通过调用On Error Resume Next函数来调用错误句柄。

< % OPTION EXPLICIT

On Error Resume Next

Dim FirstName

/app2/error_1.asp片段

基准值 = 5.57 msec/page

反应时间= 5.67 msec/page

差= 0.10 msec (1.8% 增加)

你可以看到,错误句柄带来了代价。我们可以提出以下建议:只有在会发生超出测试或控制能力之外的情况时才使用错误句柄。一个最基本的例子就是使用存取其它资源,如ADO或FileSystem 对象的COM对象。

设置一个上下文处理是否对性能有影响?

当错误发生时,在页面上设置一个上下文处理允许脚本进行反转操作。这是通过在页面上使用处理声明来设置的。

< %@ TRANSACTION = REQUIRED % >

< % OPTION EXPLICIT

Dim FirstName

/app2/transact1.asp片段

基准值 = 5.57 msec/page

反应时间= 13.39 msec/page

差 = +7.82 msec (140.4% 增加)

啊!这真实最具有戏剧性的结果。所以请留意以下规则:只有当两个或更多操作被作为一个单元执行时,才使用处理上下文。

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有