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找到。对一个写得好的ActiveX 组件进行编译不仅能大幅度提高性能，还可以保护你的软件(脚本)，尤其当你将你的Asp站点发布在第叁方主机上的时候。

　　因为脚本是逐行解释执行的，所以剔除多余的脚本或建立更高效率的脚本能够改进性能。假如你在单个Asp 文件中有数百行的代码，可能这样做你能很好地划分使用者，买卖和数据服务。其实，假如你这样做，可能会找出一些冗余的代码：假如你需要输出几个表格，你可以编写一个通用函数来输出一个表格，只是屡次调用它。

　　在讲述Asp 脚本的大小问题的时候，不得不提及包含文件的大小。当你使用一个包含文件的时候，整个包含文件被装入，当包含文件被包含的时候，相当于在Asp 文件本身写下那部分代码。因此，假如你在一个冗长的包含文件里定义了很多通用的要领和定义，要理解到在你包含该文件的时候，不管你要不要用到里面的每个方法和定义，它都是被整个装入的。ASP 缓存全部的展开代码，这会降低查找效率在这种情景下，包含文件务必被分割成更小的，模块化的文件。也要理解到包含文件被服务器视为单独的页面请求，使用太多的包含文件会影响下载时间。

　　假如你的脚本冗长的话，请使用Response.IsClientConnected。这意味着在客户端不再连接到服务器的时候，你的服务器CPU能避免循环等待。

　　Interspersing ASP and HTML

　　每个人都这样做?当我们输出表格的时候，我们会在ASP 和HTML代码间转换，而这是一个不好的习惯。好比：

　　另外一个普遍的案例是使用IF语句的时候：

　　在这些情境下，脚本性能能通过将服务器端脚本写到一起来，而用Response.write发生Html代码来提高性能。好比：

　　在大的脚本和很多脚本的情景下，你将能看到性能的提高。注意这里尽量避免了使用〈%标记，这样就能提高性能，ASP不需在执行脚本的时候计算字符的Ascii码。

　　Session状态

　　无庸置疑地，在Asp中能够通过Session维持某个状态的能力是十分强大的特色。然而，它会影响你的性能。明显地，你的站点的可伸缩性性变成了另外一个问题，如果限制Session的使用的话。然而，session会为每个用户消耗服务器资源。

　　假如你不使用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连接数据库?使用迅速的O LED B Provider技术连接你的数据库而不是使用DSN连接。不再需要恳求你的ISP(或数据库管理员/网管)为你建立一个系统DSN，当你移走Web文件的时候，亦不用改变配置。

　　O LED B 介于ODBC层和应用程序之间。在你的ASP 页面中，ADO介于ODEDB之上的“应用程序”。你的ADO调用首先被送到O LED B，接着被送到ODBC层。然而，你可以直接连接到O LED B 层，并且假如你这样做的话，你就能看到服务器端性能的提高。然而，怎样直接连接到O LED B?

　　假如你使用SQLServer 7，使用下面的连接代码连接数据库：

　　strConnString = "DSN='';DRIVER={SQL SERVER};" & _

　　"UID=myuid;PWD=mypwd;" & _

　　"DATABASE=MyDb;SERVER=MyServer;"

　　最重要的参数是DRIVER=部分。假如你要绕过ODBC而使用通过使用O LED B 连接SQL Server(这是更快的连接)，请使用下面的语法：

　　有啥不对的地方吗?

　　现在你可能会觉得有点奇怪：我们在这个新的连接方法中的要点是啥呢?为啥不使用标准DSN-less/System DSN途径?呵，根据Wrox 在他的作品《ADO 2.0 Programmer's Reference》中测试的结果表明，假如你使用O LED B连接和DSN或DSN-less连接方法比较，你会发现有下面的改进：

　　性能对照：

　　SQL Access

　　O LED BDSNO LED BDSN

　　连接时间：18?82?连接时间：62?99

　　查询1,000条记录时间：29005400查询1,000条记录时间： 100950

　　注释：这个结果在Wrox的《ADO 2.0 Programmer's Reference》一书的第232和233页可以查到。时间的单位是毫秒，查询1,000记录时间是通过服务器端游标计算出来的(当使用客户端游标的时候，O LED B与DSN记录集的性能之间的不同不大)。

　　ASP译码问题：

　　尽可能在客户端确认用户输入来减少HTTP来回请求的数量。如果浏览器有支持JavaScript或其它脚本的能力，使用它们的力量以释放更多的服务器资源。

　　下面的VBScript运行于客户端浏览器，在提交到你的服务器之前，用来验证用户信息：

　　使用局部变量，避免使用全局变量。局部变量比全局变量更快地被Asp 脚本引擎存取，因为不需搜索整个名称域。避免改变数组定义。在第壹次初始化的时候就简单分配充分的大小效率更高。在这种情景下，你可能会浪费一些内存，但你获得了速度的优势。在服务器负载重的时候这个技术是显然易见有效的。

　　假如你需要引用不务必要用到的对象，那么最好使用〈OBJECT〉标记而不是用 Server.CreateObject方法。 使用Server.CreateObject引起对象立即被建立，反之，〈OBJECT〉标记则不会这样立即建立对象如果使用〈object〉定义后不使用该对象，你不会浪费资源。

　　好比：下面的案例是一个使用〈OBJECT〉标记建立一个application-scope广告轮 Ad Rotator对象实

　　例：

　　在存储该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程序。