最大限度优化你的Asp性能
ASP 能快速执行你的动态网页，但你还可以通过紧缩代码和数据库连接以使它们执行更快。这是一
篇关于怎样精简代码和Asp 特征以获得最快执行速度的详细文章。对于一个急燥的用户来说，任何在按
下用户按钮到结果出现在它们的屏幕之间的延迟可能意味着它们会转到浏览其它的站点？假如你的是商
业站点，这有可能意味着失去潜在的销售。
我们没有任何办法控制用户的带宽，但我们的确能通过优化Asp 站点来获得最佳的性能。大部分潜
在性能的提升是通过系统改变而不是紧缩代码，一个不合适的想法是，一旦遇到系统效率问题，就向系
统管理者提意见要其升级系统。
首先，哪个因素可能影响Asp的性能？很不幸，有很多因素？下面这些只是其中的一部分：
可用带宽
服务器上的处理器和其它硬件的速度
在服务器上运行的其它程序(比如象那些OpenGL屏幕保护程序！)
数据库连接模式，连接池，数据库系统本身(比如Oracle优于Sql Server，Sql server优于Access)
所使用的语言
存储过程优于行式Sql语句
使用编译组件而不是VB或JavaScript，好的Asp编程经验，比如错误处理等
一些以上的因素可能已经被有IIS 知识经验的开发者普遍留意到了，但其它的可能对于他们来说是
十分复杂的问题。在这篇文章里， 将试着解释所有影响Asp性能的每个因素，让我们看一看那些在我们
刮胡子的几毫秒内就能做到的主要事情。
ASP脚本大小
你是脚本页(还有其它页面)是不是比必须的长度要长？这是一开始执行就会降低Asp 性能的东西。
ASP 脚本在用来获取信息和格式化输出的时候是十分有用的，但脚本也是逐行解释执行，所以你的脚本
越长，执行它的时间也就越长。
如果你的脚本很庞大，怎么做才能减少脚本的长度呢？这里有几点建议：
你可以将它们转换成服务器端组件，也就是说，做成VB动态链接库DLL或者通过先进的Windows编程
语言或适当的COM 接口语言将它转换成未编译组件？并且在服务器端注册它们。有关的快速指南可以在
http://www.webdevelopersjournal.com/articles/activex_for_asp.html找到。对一个写得好的Activ
eX 组件进行编译不但能大幅度提高性能，还可以保护你的软件(脚本)，尤其当你将你的Asp站点发布在
第三方主机上的时候。
因为脚本是逐行解释执行的，所以剔除多余的脚本或建立更高效率的脚本能够改进性能。如果你在
单个Asp 文件中有数百行的代码，可能这样做你能很好地划分使用者，买卖和数据服务。事实上，如果
你这样做，可能会找出一些冗余的代码：如果你需要输出几个表格，你可以编写一个通用函数来输出一
个表格，只是多次调用它。
在讲述Asp 脚本的大小问题的时候，不得不提及包含文件的大小。当你使用一个包含文件的时候，
整个包含文件被装入，当包含文件被包含的时候，相当于在Asp 文件本身写下那部分代码。因此，如果
你在一个冗长的包含文件里定义了很多通用的方法和定义，要明白到在你包含该文件的时候，不管你要
不要用到里面的每个方法和定义，它都是被整个装入的。ASP 缓存全部的展开代码，这会降低查找效率
在这种情况下，包含文件必须被分割成更小的，模块化的文件。也要明白到包含文件被服务器视为单独
的页面请求，使用太多的包含文件会影响下载时间。
<!-- #include file="Header.asp" -->
<!-- #include file="Footer.asp" -->
<SCRIPT language="vbscript" runat="server">
Sub Main()
WriteHeader
WriteBody
WriteFooter
End Sub
Sub WriteBody()
...
End Sub
Main '调用过程Main
</SCRIPT>
假如你的脚本冗长的话，请使用Response.IsClientConnected。这意味着在客户端不再连接到服务
器的时候，你的服务器CPU能避免循环等待。
<%
'检查客户端是否仍在连接
If Not Response.IsClientConnected Then
'仍然连接着，处理程序
Else
'断开
End If
%>
Interspersing ASP and HTML
每个人都这样做？当我们输出表格的时候，我们会在ASP 和HTML代码间转换，而这是一个不好的习
惯。例如：
<HTML>
<BODY>
<%
Set MyConn = Server.CreateObject("ADODB.Connection")
MdbFilePath = Server.MapPath("sample.mdb")
MyConn.Open "Driver={Microsoft Access Driver (*.mdb)}; DBQ=" & MdbFilePath & ";"
SQL_query = "SELECT * FROM Friends"
Set RS = MyConn.Execute(SQL_query)
WHILE NOT RS.EOF
%>
<LI><%=RS("Name")%>: <A HREF="">Homepage</A>
<%
RS.MoveNext
WEND
%>
</BODY>
</HTML>
另一个普遍的例子是使用IF语句的时候：
<%
If Not Session("DBOpen") Then
%>
<H1>Database not connected</H1>
<%
Else
%>
<H1>Database open</H1>
<%
End If
%>
在这些情况下，脚本性能能通过将服务器端脚本写到一起来，而用Response.write产生Html代码来
提高性能。比如：
<%
If not Session ("DBOpen") Then
Response.Write "<H1>Database not connected</H1>"
Else
Response.Write "<H1>Database open</H1>"
End If
%>
在大的脚本和很多脚本的情况下，你将能看到性能的提高。注意这里尽量避免了使用<%标记，这
样就能提高性能，ASP不需在执行脚本的时候计算字符的Ascii码。
Session状态
无庸置疑地，在Asp中能够通过Session维持某个状态的能力是十分强大的特色。然而，它会影响你
的性能。明显地，你的站点的可伸缩性性变成了另一个问题，如果限制Session的使用的话。然而，ses
sion会为每个用户消耗服务器资源。
如果你不使用session 变量，或事实上你不必使用？使用隐藏表单域，在数据库中保存数据，查询
字符串是不是其中的窍门？所以你应该禁止Session状态。你可以使用下面的声明禁止使用session：
@EnableSessionState = False
这样，ASP将不再检查session信息。
如果你不得不依赖于session状态，应该避免在session对象中存放大量的数据。IIS中的session在
客户端的HTTP cookie可用的时候就会保持，导致被session占用的内存在session 终止或超时前一直被
占用。这样，如果很多用户同时使用你的程序的时候，你的服务器资源可能会耗尽。
数据库访问
数据库访问是必须的麻烦？访问数据库将会激烈地减慢你的程序，但很显然，如果没有数据库，很
多站点将变得毫无价值可言。但通过存储过程访问数据库来代替使用嵌入式Sql 语句，你可以提升潜在
的性能。通过使用存储过程和ActiveX Data Objects (ADO)，它们亦同样拥有良好的灵活性。尽可能从
存储过程来输出数据。
确认你的数据库具有索引，因为这样能直接提高你的程序的效率。同样，尽量在你的数据库服务器
运行更新统计(Update Statistics) 以帮助追踪你的数据分发，这样，你的数据库就能够基于这些信息
来改造查询执行。注意一些数据库比如MS Access，是不是真正能在企业级程序中接受？SQL Sever 7.0
或者Oracle是一个更好的赌注。
让SQL象它被设计的那样工作，它能count(统计)，连接(join)，排序(sort)和group 数据。当你能
够写出一个查询语句来做这些东西的时候，就不要自己用其它语言来实现。
下面是一个统计所有列的最简单的语法：
SELECT count(*) FROM publishers WHERE state='NY'
如果你统计一个指定的列，你必须使用group by语句来分组该列，否则它不会工作：
SELECT count(city),city FROM publishers GROUP BY city
分类返回的数据：
SELECT * FROM TableName WHERE FieldName>50 OR FieldName<100 ORDER BY FieldName2, Field
Name3
使用Odbc还是文件DSN连接数据库？使用快速的OLEDB Provider技术连接你的数据库而不是使用DSN
连接。不再需要恳求你的ISP(或数据库管理员/网管)为你建立一个系统DSN，当你移走Web文件的时候，
亦不需要改变配置。
OLEDB 介于ODBC层和应用程序之间。在你的ASP 页面中，ADO介于ODEDB之上的“应用程序”。你的
ADO调用首先被送到OLEDB，接着被送到ODBC层。然而，你可以直接连接到OLEDB 层，并且如果你这样做
的话，你就能看到服务器端性能的提高。然而，怎样直接连接到OLEDB？
如果你使用SQLServer 7，使用下面的连接代码连接数据库：
strConnString = "DSN='';DRIVER={SQL SERVER};" & _
"UID=myuid;PWD=mypwd;" & _
"DATABASE=MyDb;SERVER=MyServer;"
最重要的参数是DRIVER=部分。如果你要绕过ODBC而使用通过使用OLEDB 连接SQL Server(这是更快
的连接)，请使用下面的语法：
strConnString ="Provider=SQLOLEDB.1;Password=mypassword;" & _
"Persist Security Info=True;User ID=myuid;" & _
"Initial Catalog=mydbname;" & _
"Data Source=myserver;Connect Timeout=15"
有什么不对的地方吗？
现在你可能会觉得有点奇怪：我们在这个新的连接方法中的要点是什么呢？为什么不使用标准DSN-
less/System DSN途径？呵，根据Wrox 在他的著作《ADO 2.0 Programmer's Reference》中测试的结果
表明，如果你使用OLEDB连接和DSN或者DSN-less连接方法比较，你会发现有下面的改进：
性能对比：
SQL Access
OLEDB DSN OLEDB DSN
连接时间： 18 82 连接时间： 62 99
查询1,000条记录时间：2900 5400 查询1,000条记录时间： 100 950
注释：这个结果在Wrox的《ADO 2.0 Programmer's Reference》一书的第232和233页可以查到。时
间的单位是毫秒，查询1,000记录时间是通过服务器端游标计算出来的(当使用客户端游标的时候，OLED
B与DSN记录集的性能之间的差别不大)。
ASP译码问题：
尽可能在客户端确认用户输入来减少HTTP来回请求的数量。如果浏览器有支持JavaScript或其它脚
本的能力，使用它们的力量以释放更多的服务器资源。
下面的VBScript运行于客户端浏览器，在提交到你的服务器之前，用来验证用户信息：
<SCRIPT LANGUAGE="VBScript">
<!--
Sub btnEnter_OnClick
Dim TheForm
Set TheForm = Document.MyForm
If IsNumeric(TheForm.Age.Value) Then
TheForm.submit
Else
Msgbox "Please enter a numerical age."
End if
End Sub
//-->
</SCRIPT>
<FORM method="POST" name=MyForm action="myfile.asp">
Name: <INPUT typr="text" name="Name">
Age: <INPUT type="text" name="Age">
<INPUT type="button" name="btnEnter" value="Enter">
</FORM>
使用局部变量，避免使用全局变量。局部变量比全局变量更快地被Asp 脚本引擎存取，因为不需搜
索整个名称域。避免改变数组定义。在第一次初始化的时候就简单分配足够的大小效率更高。在这种情
况下，你可能会浪费一些内存，但你获得了速度的优势。在服务器负载重的时候这个技术是显然易见有
效的。
如果你需要引用不一定要用到的对象，那么最好使用<OBJECT>标记而不是用 Server.CreateObject
方法。 使用Server.CreateObject引起对象立即被建立，反之，<OBJECT>标记则不会这样立即建立对象
如果使用<object>定义后不使用该对象，你不会浪费资源。
例如：下面的例子是一个使用<OBJECT>标记建立一个application-scope广告轮 Ad Rotator对象实
例：
<OBJECT runat=server scope=Application id=MyAds progid="MSWC.AdRotator">
</OBJECT>
在存储该Ad Rotator对象进Application后，你可以在任何程序的页面中用下面的语法访问该对象
<%=MyAds.GetAdvertisement("CustomerAds.txt") %>
打开'Option Explicit'开关。在VB和VBScript 中，你可以在没有显式声明的情况下使用变量。但
打开这个选项可以鉴别用定义变量，这样可以很好地书写变量，并能帮助提高性能。未定义的局部变量
会变慢，因为在建立它之前，名称空间必须被搜遍后才知道变量是否存在。摆脱它，使每个变量清楚地
定义(先定义后使用)。
这是一个好习惯，it may trap typos, 这样更快。
除非你真正需要使用，否而不要使用Server.MapPath方法。如果你知道真实路径就使用真实路径。
使用MapPath需要IIS找回现时服务器路径，这意味着得向服务器发一个特殊的请求，也就意味着降低了
性能。另一个方法是将路径存放到局部变量中，在需要的时候使用，这样就不需要服务器多次查找。
检查你自己是怎么做的
你可以通过工具来测量你的系统性能，比如系统性能监视器，NetMon和PerfMon。测试web性能可以
用WCAT (Web Capacity Analysis Tool)。使用WCAT，你可以测试你的IIS服务器和网络配置响应各种各
样的客户请求，数据或HTML页面的能力。这些测试结果能够被用来作为优化你的服务器和网络配置的指
导。WCAT是专门设计用来估计Windows 2000中的因特网服务(或Windows NT)和IIS 能响应的客户工作量
(仿真)。为了得到更多的信息，请参阅IIS Resource Kit(资源工具包)。那里也有冗长的WCAT用户指南
在MSDN在线Web sorkshop站点里面有一个下载链接。如果你认真对待你的Asp 性能的话，务必取得该工
具。
力求最优化应用程序性能，你的web 应用程序会运行更加顺畅。如果不是真正需要，就不要影响服
务器的性能。
摘要：
上面介绍了有关ASP性能的资料，有很多因素影响Asp的性能，这里只讨论了其中的一部分。作为最
终的想法，不要认为你能够处理好所有的因素，你的ASP 性能还是有必要提高的。你发布的每个应用程
序必须个别进行考虑，所有以上的技巧并不是适合每个Asp程序。