微软建议的ASP性能优化28条守则(8)

　　技巧 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=?
Workshop?>


这也适用于指向 Web 站点上主页的 URL：使用下面的：<a href=?，而不使用 <a href=?。

技巧 24：避免使用服务器变量
访问服务器变量会使 Web 站点向服务器发出一个特殊请求，并收集所有服务器变量，而不只是您请求的那个变量。这种情况类似于，在发霉的阁楼上，在一个文件夹中查找某个文件。当您想要找那个文件时，您必须去阁楼上，先找到文件夹，然后才能找到这份文件。当您请求服务器变量时，发生的情况是一样的 - 您第一次请求服务器变量时，就会使性能受到影响。后面的对其它服务器变量的请求，则不会对性能产生影响。

决不要访问非限定的 Request 对象（例如，Request(Data)）。对于不在kies、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 文档）可以显著改善性能，特别是在倾向于等待后端资源（如数据库）或其它中间产品（如屏幕刷）的站点上。在 IIS 5.0 中，您可能发现启用 ASP Thread Gating 比查找一个 AspProcessorThreadMax 最佳设置效率更高，这一点现在已为大家所熟知。

有关较好的参考资料，参见下面的优化 IIS。

最佳的配置设置取决于（其中一些因素）应用程序代码、运行所在的系统硬件和客户机工作负荷。找到最佳设置的唯一方法是进行性能测试，这是我们在下一个技巧中所要讨论的。

技巧 27：进行性能测试
正如我们在前面已经讲过，性能是一个特征。如果您想要改善站点的性能，那么就制定一个性能目标，然后逐步改进，直到达到目标为止。不要，就不进行任何性能测试。通常，在项目结束时，再作必需的结构调整已经为时太晚，您的客户将为此感到失望。将性能测试作为您日常测试的一部分来进行。可以对单个组件分别进行性能测试，如针对 ASP 页或 COM 对象，或将站点作为一个整体来测试。

许多人使用单个浏览器请求页面，来测试 Web 站点的性能。这样做就会给您一个感觉，即站点的响应能力很好，但这样做实际上并不能告诉您在负载条件下站点的性能如何。

一般情况下，要想准确地测试性能，您需要一个专门的测试环境。此环境应包括硬件，其处理器速度、处理器数量、内存、磁盘、网络配置等方面与生产环境的硬件相似。其次，您必须指定客户机的工作负荷：有多少同时的用户，他们发出请求的频率，他们点击页面的类型等等。如果您没有站点实际使用情况的数据，您必须估计一下使用的情况。最后，您需要一个可以模拟预期客户机工作负荷的工具。有了这些工具，您就可以开始回答诸如“如果我有 N 个同时的用户，那么需要多少服务器？”之类的问题。您还可以找出出现瓶颈的原因，并以此为目标进行优化。

下面列出了一些好的 Web 负载测试工具。我们特别推荐 Microsoft Web Application Stress (WAS) 工具包。WAS 可使您记录测试脚本，然后模拟数百或成千上万个用户访问 Web 服务器。WAS 报告很多统计信息，包括每秒钟的请求数，响应时间分布情况和错误计数。WAS 有丰富的客户机界面和基于 Web 的界面两种，Web 界面可使您进行远程测试。

一定要阅读 IIS 5.0 Tuning Guide。