ASP开发人员为了在他们的设计项目中获得更好的性能和可扩展性而不断努力。幸运地是，有许多书籍和站点在这方面提供了很好的建议。但是这些建议的基础都是从ASP平台工作的结构上所得出的结论，对实际获得的性能的提高没有量的测量。由于这些建议需要更加复杂的编码过程并降低了编码的可读性，开发人员就只能在看不到实际运行效果的情况下，独自衡量为了提高他们ASP应用程序的性能是否值得付出这些代价。
本文分为两大部分，我将介绍一些性能测试结果，帮助开发人员来确定某一特定举措是否不仅对将来的项目来说是值得的，并且能够对原来的项目进行更新。在第一部分我将回顾一些ASP开发的基础性问题。在第二部分，将涉及一些最优化ADO函数，并将它们的结果与调用VB COM对象执行相同ADO函数的ASP页面进行比较。这些结果很让人开眼界，甚至有些时候是很令人吃惊的。
在本文中，我们将回答以下问题：
* 将ASP生成的内容写入响应流中最有效的方法是什么？
* 是否应该开启缓冲器？
* 是否应该考虑向ASP代码中增加注释？
* 是否应该为页面明确地设置默认语言？
* 如果不需要，是否应该关闭Session 状态？
* 是否应该把脚本逻辑放在子程序和函数区中？
* 使用包含文件有什么影响？
* 执行错误处理时会施加什么样的负载？
* 设置一个上下文处理是否对性能有影响？
所有测试都是用Microsoft的Web应用程序重点工具(WAST)来进行的，这是一个免费的工具，可以在这里找到。我用WAST创建了一个简单的test 脚本，反复调用下面所描述的ASP页面测试（每个超过70，000次）。反应的时间基于平均最后字节总时间(TTLB), 也就是从最初请求的时间到工具从服务器接收最后一位数据的时间。我们的测试服务器是一个Pentium 166，内存为196MB，客户机为Pentium 450，内存为256MB。你也许会想这些机器的性能并不算很高级，但是不要忘了，我们并不是要测试服务器的容量，我们只是要测试服务器每次处理一个页面所用的时间。测试期间这些机器不做其它工作。WAST 测试脚本、测试报告以及所有的ASP测试页面都包含在ZIP文件中，你可以自己进行回顾和测试。
将ASP生成的内容写入响应流中最有效的方法是什么？
使用ASP的一个最主要原因是在服务器上生成动态内容。所以很明显，我们测试的起点是确定将动态内容发送到响应流中的最适合的方式。在多种选择中，有两个是最基本的：一是使用内联ASP标记，另一个是使用Response.Write 语句。
为测试这些选择，我们创建了一个简单的ASP页面，其中定义了一些变量，然后将它们的值插入表格中。虽然这个页面很简单也不是很实用，但它允许我们分离并测试一些单独的问题。
使用ASP内联标记
第一个测试包括使用内联ASP标记＜ %= x % ＞，其中x是一个已赋值的变量。到目前为止，这个方法是最容易执行的，并且它使页面的HTML部分保持一种易于阅读和维护的格式。
＜ % 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"
% ＞
＜ 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的完整代码
以前的最佳（反应速度） = 8.28 msec/page
在HTML的每一行使用Response.Write 语句
许多比较好的学习文档建议避免使用前面的那种方法。其主要理由是，在输出页面和处理页面施加反应时间的过程中，如果web 服务器不得不在发送纯HTML和处理脚本之间进行转换，就会发生一种被称为上下文转换的问题。大部分程序员一听到这里，他们的第一反应就是将原始的HTML的每一行都包装在Response.Write函数中。
…
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 ＞")
… <
/app1/response2.asp的片段
以前的最佳（反应速度） = 8.28 msec/page
反应时间 = 8.08 msec/page
差= -0.20 msec (减少 2.4%)
我们可以看到，使用这种方法与使用内联标记的方法相比在性能上获得的收益非常小，这也许是因为页面给服务器装载了一大堆小的函数调用。这种方法最大的缺点是，由于现在HTML都嵌入脚本中，所以脚本代码变得更加冗长，更加难以阅读和维护。
使用包装函数
当我们试图使用Response.Write 语句这种方法时，最令人灰心的发现可能就是Response.Write 函数不能在每行的结尾处放置一个CRLF 。因此，当你从浏览器中阅读源代码时，本来布置得非常好的HTML，现在成了没有结束的一行。我想，你的下一个发现可能会更令你恐怖：在Response 对象中没有其姊妹函数Writeln 。所以，一个很明显的反应就是为Response.Write 函数创建一个包装函数，以便给每一行都附加一个CRLF 。
…
writeCR("＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" & FirstName & "＜ /td ＞＜ /tr ＞")
…
SUB writeCR(str)
Response.Write(str & vbCRLF)
END SUB
/app1/response4.asp的片段
以前的最佳（反应速度）= 8.08 msec/page
反应时间= 10.11 msec/page
差 = +2.03 msec (增加 25.1%)
当然，由于这种方法有效地使函数调用次数加倍，其对性能的影响也很明显，因此要不惜一切代价避免。具有讽刺意味的是CRLF也向反应流中为每行增加了2个字节，而这是浏览器不需要呈现到页面上的。格式化良好的HTML所做的一切就是让你的竞争者更容易阅读你的HTML源代码并理解你的设计。
将连续的Response.Write 连接到一个单独语句中
不考虑我们前面用包装函数进行的测试，下一个合乎逻辑的步骤就是从单独的Response.Write 语句中提取出所有的字符串，将它们连接到一个单独语句中，这样就减少了函数调用的次数，极大地提高了页面的性能。
…
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 ＞")
/app1/response3.asp的片段
以前的最佳（反应速度）= 8.08 msec/page
反应时间 = 7.05 msec/page
差 = -1.03 msec (减少12.7%)
目前，这是最优化的配置。
将连续的Response.Write 连接到一个单独语句中，在每行结尾处增加一个CRLF
考虑到那些要求他们的源代码从浏览器中看要很纯粹的人，我用vbCRLF 常量在前面测试中每行的结尾处插入了一些回车，然后重新运行。
…
Response.Write("＜ html ＞" & vbCRLF & _
"＜ head ＞" & vbCRLF & _
" ＜ title ＞Response Test＜ /title ＞" & vbCRLF & _
"＜ /head ＞" & vbCRLF & _
…
/app1/response5.asp的片段
前面的最佳（反应速度）= 7.05 msec/page
反应时间= 7.63 msec/page
差 = +0.58 msec (增加 8.5%)
运行的结果在性能上有一点降低，这也许是由于额外的串联和增加的字符量。
回顾和观测
从前面有关ASP输出的测试中可以得出一些规则：
* 避免内联ASP的过多使用。
* 总是将连续Response.Write 语句连接进一个单独语句内。
* 永远不要在Response.Write 周围使用包装函数来附加CRLF。
* 如果必须格式化HTML输出，直接在Response.Write 语句内附加CRLF。
是否应该开启缓冲器？
通过脚本程序启动缓冲器
在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% 增加)
啊！这真实最具有戏剧性的结果。所以请留意以下规则：只有当两个或更多操作被作为一个单元执行时，才使用处理上下文。
结论
本文第一部分的重要之处在于许多小事情的累积。为了强调这个问题，我设置了最后一个测试，在其中进行了我们以前曾经测试过的看来无所谓但实际上有坏影响的所有操作。我包含了许多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 文件。
* 在一个页面上，如果代码要使用一次以上，就将代码封入函数区。
* 适当时候，将变量声明移到函数范围内。
* 只有会发生超出测试或控制能力之外的情况时才使用错误句柄。
* 只有当两个或更多操作被作为一个单元执行时，才使用上下文处理。
现在回顾一下，有许多问题可以作为普遍性的方针：
* 避免冗余--不要设置那些默认状态下已经设置的属性。
* 限制函数调用的次数。
* 缩小代码的范围。
相关提高ASP性能的最佳选择