技巧 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 调试指南（英文）。
