很长时间，您可能还想按一定的时间间隔检查 Response.IsClientConnected。在启用响应缓冲之后，按一定的时间间隔执行 Response.Flush，告诉用户正在进行的是哪些事情，是个好办法。
注意 在 IIS 4.0 中，Response.IsClientConnected 将不能正常工作，除非首先执行 Response.Write。如果启用了缓冲，也需要执行 Response.Flush。在 IIS 5.0 中则不必如此 - Response.IsClientConnected 工作得很好。在任何情况下，Response.IsClientConnected 都要有些开销，所以，只有在执行至少要用 500 毫秒（如果想维持每秒几十页的吞吐量，这是一个很长的时间了）的操作前才使用它。作为通常的规则，不要在紧密循环的每次迭代中调用它，例如当绘制表中的行，可能每 20 行或每 50 行调用一次。
技巧 17：使用 <OBJECT> 标记实例化对象
如果需要引用不能在所有代码路径中使用的对象（尤其是服务器 - 或应用程序 - 作用域的对象），则使用 Global.asa 中的 <object runat=server id=objname> 标记来声明它们，而不是使用 Server.CreateObject 方法。Server.CreateObject 立刻创建对象。如果以后不使用那个对象，就不要浪费资源。<object id=objname> 标记声明了 objname，但实际上 objname 此时并没有创建，直到它的方法或属性第一次被使用时才创建。
这是迟缓计算的另一个例子。
技巧 18：使用 ADO 对象和其他组件的 TypeLib 声明
当使用 ADO 时，开发人员经常包含 adovbs.txt 来获得对 ADO 不同常量的访问权。该文件必须包含在要使用这些常量的每一页中。该常量文件非常大，给每个 ASP 页增加了很多编译时间和脚本大小方面的开销。
IIS 5.0 提供了绑定到组件类型库的能力。允许您在每个 ASP 页上引用一次类型库并使用它。每页不需要为编译常量文件付出代价，并且组件开发人员不必为在 ASP 中的使用而生成 VBScript #include 文件。
要访问 ADO 类型库，请将下列语句之一放入 Global.asa 中。
<!-- METADATA NAME="Microsoft ActiveX Data Objects 2.5 Library"
TYPE="TypeLib" UUID="{00000205-0000-0010-8000-00AA006D2EA4}" -->
或者
<!-- METADATA TYPE="TypeLib"
FILE="C:Program FilesCommon Filessystemadomsado15.dll" -->
技巧 19：利用浏览器的验证能力
流行的浏览器具有对以下功能的高级支持，例如 XML、DHTML、Java 小程序以及远程数据服务。请尽量利用这些功能。所有这些技术，都可以通过执行客户端的验证和数据缓存，减少了与 Web 服务器之间的往返。如果您正在运行智能浏览器，该浏览器可以为您进行一些验证（例如，在运行 POST 之前检查信用卡的校验和否有效）。重申一次，请尽量使用这些功能。由于削减了客户端到服务器的往返路程，将减少对 Web 服务器的压力，并且削减了网络通信量（虽然发送给浏览器的初始页面可能更大），服务器访问的所有后端资源也削减了。而且用户不必经常提取新页，使用户的感受好一些。这并不减轻对服务器端验证的需要。还是应该经常进行服务器端的验证。这样能够防止由于某些原因从客户端来的坏数据，例如黑客，或者不运行客户端验证程序的浏览器。
许多站点由独立于浏览器创建的 HTML 组成。这一点经常阻碍开发人员利用可以提高性能的流行浏览器功能。对于真正高性能的、必须关心浏览器的站点，良好的策略是针对流行的浏览器优化您的页面。在 ASP 中使用“浏览器性能组件”，很容易检测到浏览器的功能。诸如 Microsoft FrontPage 等工具，能帮助您设计使用所希望的目标浏览器和 HTML 版本的代码。更详细的讨论，请查看 When is Better Worse? Weighing the Technology Trade-Offs（英文）。
技巧 20：在循环中避免字符串串联
许多人在循环中创建类似这样的字符串：
s = "<table>" & vbCrLf
For Each fld in rs.Fields
s = s & " <th>" & fld.Name & "</th> "
Next
While Not rs.EOF
s = s & vbCrLf & " <tr>"
For Each fld in rs.Fields
s = s & " <td>" & fld.Value & "</td> "
Next
s = s & " </tr>"
rs.MoveNext
Wend
s = s & vbCrLf & "</table>" & vbCrLf
Response.Write s
这种方法有几个问题。首先，重复连接字符串所花费的时间，以二次方曲线的速率增长；粗略地计算，运行循环所花费的时间，与记录数乘以字段数的平方成正比。举一个简单的例子，便能清楚地说明这一点。
s = ""
For i = Asc("A") to Asc("Z")
s = s & Chr(i)
Next
在第一次迭代中，得到一个字符的字符串“A”。在第二次迭代中，VBScript 必须重新分配字符串并复制两个字符“AB”到 s。在第三次迭代中，它必须再次重新分配 s，并复制三个字符到 s。在第 N 次（26 次）迭代中，它必须重新分配并复制 N 个字符到 s。就是 1+2+3+...+N 的和，为 N*(N+1)/2 次复制。
在以上记录集的例子中，如果有 100 条记录和 5个字段，则内部的循环将执行 100*5 = 500 次，并且完成所有复制和重新分配所花费时间，将与 500*500 = 250,000 成正比。对一个大小适度的记录集，将有很多次复制。
在该例子中，代码可以改进：字符串的连接将被 Response.Write() 或内嵌脚本 (<% = fld.Value %>) 所替代。如果打开响应缓冲，这个操作将会很快，因为 Response.Write 仅仅将数据添加到响应缓冲的末尾。不再重新分配，因而非常有效。
特别是在将 ADO 记录集转换到 HTML 表时，请考虑使用 GetRows 或 GetString。
如果用 JScript 连接字符串，强烈建议使用 += 操作符；即用 s += "某字符串"， 而不是 s = s + "某字符串"。
技巧 21：启用浏览器和代理缓存
默认情况下，ASP 禁用浏览器和代理中的缓存。这将很有意义，因为 ASP 生来就是动态的，具有潜在地对时间敏感的信息。如果有一个不需要对每次查看进行刷新的页，则应该启用浏览器和代理缓存。这使得浏览器和代理能在某一段时间内，使用某一页的缓存副本，这时间的长短可以控制。缓存能明显减轻服务器负荷，使用户的感受好一些。
哪种动态页可以缓存？举例说明：
天气页，每 5 分钟更新一次。
列出新闻的主页或新闻发布的主页，每天更新 2 次。
公共基金运营列表，基本的统计数小时更新 1 次。
请注意，使用浏览器或代理缓存，只有很少的命中被记录到 Web 服务器上。如果想精确测量所有页面查看或者张贴广告，也许不喜欢使用浏览器和代理缓存。
浏览器缓存是由 Web 服务器发往浏览器的 HTTP 截至期限标题控制的。ASP 提供了两种发送标题的机制。要将页面设置为在未来某个分钟数后过期，请设置 Response.Expires 属性。以下的例子通知浏览器：内容在 10 分钟后过期：
<% Response.Expires = 10 %>
设置 Response.Expires 为负数或 0 则禁用缓存。一定要使用较大的负数，例如 -1000 （大于一天），来克服服务器时钟和浏览器时钟之间的差异。第二个属性 Response.ExpiresAbsolute，允许设置内容过期的指定时间：
<% Response.ExpiresAbsolute = #May 31,2001 13:30:15# %>
如果不想使用 Response 对象设置过期时间，可以将 <META> 标记写入 HTML，通常写在 HTML 文件的 <HEAD> 内部。一些浏览器会响应这条指令，但代理不会。
<META HTTP-EQUIV="Expires" VALUE="May 31,2001 13:30:15">
最后，可以标识内容对 HTTP 代理缓存是否有效，请使用 Response.CacheControl 属性。设置属性为“Public”，允许代理缓存内容。
<% Response.CacheControl = "Public" %>
默认情况下，该属性设置为“Private”。注意，不应当为显示某用户专用数据的页启用代理缓存，因为代理也许为属于其他用户的用户页面服务。
技巧 22：尽可能使用 Server.Transfer 替代 Response.Redirect
Response.Redirect 通知浏览器，请求一个不同的页面。该函数经常用于重定向用户到登录或错误页面。既然重定向强制一个新页请求，浏览器就必须做两次到 Web 服务器的往返，而且 Web 服务器必须处理额外的请求。IIS 5.0 引入一个新的函数，Server.Transfer，该函数执行传送到相同服务器上的不同 ASP 页。这样避免了额外的、从浏览器到 Web 服务器的往返，从而改善了整体系统性能，同时改善了对用户的响应时间。请查看重定向中的新方向（英文），它讨论了 Server.Transfer 和 Server.Execute。
也可以查看Leveraging ASP in IIS 5.0中有关 IIS 5.0 和 ASP 3.0 新功能的完全列表。（英文）
技巧 23：在目录 URL 尾部加斜线
相关的技巧是，一定要定在指向目录的 URL 尾部加斜线 (/)。如果省略了斜线，浏览器将向服务器提出请求，仅通知它正寻找一个目录。然后浏览器发出第二个请求，在 URL 末尾添加斜线，然后服务器将那个目录的默认文档作为响应，或者如果没有默认文档并且目录浏览已被启用，就以目录列表作为响应。添加了斜线便省去了第一个没用的往返。出于对用户的友好，也许想要在显示的名称的末尾省略斜线。
例如，写：
<a href="http://msdn.microsoft.com/workshop/" title="MSDN Web
Workshop">http://msdn.microsoft.com/workshop</a>
它还适用于指向在 Web 站点主页的 URL：请使用下面的： <a href="http://msdn.microsoft.com/">，不要用 <a href="http://msdn.microsoft.com">.
技巧 24：避免使用服务器变量
访问服务器变量将引起 Web 站点向服务器提出特殊的请求，然后收集所有的服务器变量，并不止是需要的那个。这好像从发霉的阁楼中的文件夹中检索某条特殊的信息一样。当想要某条信息时，在访问该信息之前必须先上阁楼取得文件夹。这与请求服务器变量时，性能访问出现第一次请求服务器变量所发生的一样。后续的对其他服务器变量的访问不会引起性能访问。
从不访问不合格的 Request 对象（例如，Request("Data")）。对于不在 Request.Cookies、Request.Form、Request.QueryString 或 Request.ClientCertificate 中的项，有对 Request.ServerVariables 的隐含调用。Request.ServerVariables 集合比其他集合慢很多。
技巧 25：升级为最新的和最好的版本
系统组件常常升级，建议升级为最新的和最好的版本。最好升级到 Windows 2000（还有，IIS 5.0、ADO 2.5、MSXML 2.5、Internet Explorer 5.0、VBScript 5.1 和 JScript 5.1）。IIS 5.0 和 ADO 2.5 在多处理器计算机上实现了非常好的性能。在 Windows 2000 下，ASP 能良好地扩展到四个处理器或者更多，但是在 IIS 4.0，ASP 不能扩展为超过两个处理器。在应用程序中使用的脚本和 ADO 越多，升级到 Windows 2000 后获得的性能提高就越大。
如果您还无法升级到 Windows 2000 ，可以升级为最新版本的 SQL Server、ADO、VBScript 和 JScript、MSXML、Internet Explorer 和 NT 4 Service Packs。它们都改进了性能并增强了可靠性。
技巧 26：调整 Web 服务器
有许多 IIS 调节参数可以改进站点性能。例如，使用 IIS 4.0，我们经常发现增加 ASP 的 ProcessorThreadMax 参数（请参阅 IIS 文档）能获得很大的好处，尤其是在经常等待后端资源，例如数据库或其他中间层产品，例如 screen-scrapers，的站点上。在 IIS 5.0 中也许会发现，打开 ASP Thread Gating 比试图为 AspProcessorThreadMax 找一个最佳的设置更为有效。
下面的调整 IIS（英文），是一篇很好的资料。
最佳的配置取决于（在其他因素中）应用程序代码、在其上运行的硬件以及客户端的工作负荷。发现最佳设置的唯一方法是运行性能测试，它将我们带入下一个技巧。
技巧 27：进行性能测试
如上所述，性能是一种指标。如果您正努力改进站点的性能，请先设置性能目标，然后提高性能直到达到目标为止。请不要将所有的性能测试放在项目的最后。往往到了项目的最后，再做非做不可的体系结构改动已为时太晚，并使客户失望。性能测试是日常测试的一部分。性能测试可以针对独立组件进行，例如 ASP 页面或 COM 对象，也可以将站点作为一个整体进行。
许多人使用单一的浏览器请求页面来测试他们 Web 站点的性能。这将使您对站点的响应有很好的感觉，但对于站点在有负荷下的性能却一无所知。
通常，要准确地测量性能，需要专用的测试环境。这个环境应该由那些，在处理器速度、处理器个数、内存、硬盘、网络配置等方面，能模拟产品硬件的硬件组成。然后，需要定义客户端的工作负荷：有多少并发用户；他们提出请求的频率；他们将访问的页面类型等等。如果您无法从站点获得实际的使用数据，则需要估计它们。最后，需要一个能模拟预期客户端工作负荷的工具。在这些工具的帮助下，可以开始回答一些问题，例如，如果我有 N 个并发用户，需要多少台服务器？您还能找出瓶颈和优化的目标。
下面列出了一些好的 Web 强度测试工具。极力推荐“Microsoft Web 应用程序强度测试 (WAS)”工具包。WAS 允许记录测试脚本，然后模拟成百或上千个访问 Web 服务器的用户。WAS 报告大量统计结果，包括每秒请求数、响应时间的分布和错误计数。WAS 具有增强客户端和基于 Web 的接口；Web 接口允许进行远程测试。
请务必阅读 IIS 5.0 调试指南（英文）。
上一页 [1] [2] [3] [4]
打印本文 
关闭窗口