监视和调整 Web 应用程序性能

如果 Web 应用程序运行速度较慢或不能正常运行，那么服务器的性能会受影响。此主题介绍了如何监视和调整应用程序，以改善服务器性能。

注意将设计拙劣的应用程序升级为设计良好的应用程序并进行彻底的测试可以显著地改善服务器性能。然而，请记住，Web 应用程序可能会受后端延迟（如旧系统和远程数据源）的影响。如果开发人员设计的应用程序用于从另一个网站、服务、或服务器获取数据，并且该远程实体出现问题，那么您的服务器可能出现瓶颈，该瓶颈可能是您无法解决的。

可以监视下列性能计数器以判断 Web 应用程序是否在服务器上制造了瓶颈。

ASP 计数器

如果正在服务器上运行 Active Server Page (ASP) 应用程序，这些计数器可以帮助您判断应用程序的运行状况如何。计数器是作为 ASP 宿主的所有进程的 ASP 性能计数器的总和，无法按进程进行细分。有关 ASP.NET 应用程序性能监视的信息，请参阅 ASP.NET 性能监视。

计数器	描述
Active Server Pages\ Requests/Sec	排除对静态文件或其他动态内容的请求，并可能随 ASP 页的复杂程度和 Web 服务器的容量而大幅度波动。如果此计数器在服务器上的流量高峰期间较低，则说明应用程序可能引起了瓶颈。
Active Server Pages\ Requests Executing	说明当前正在执行的请求的数量（例如，活动工作线程的数量）。Request Execution Time 可能会有点误导，因为它不是平均值。例如，如果您定期接收到 30 个页面请求［在 10 毫秒 (ms) 内执行］，对于每个页面请求来说（在 500 ms 内执行），该计数器可能指示 10 ms，虽然平均执行时间超过 25 ms。很难给出 Requests Executing 的理想值。如果页面执行速度很快并且不等待 I/O（例如，加载文件或进行数据库查询），那么此数字很可能较低（当计算机较忙时和处理器的数量无差别）。如果页面必须等待 I/O，那么执行的页数可能更高（最高为 AspProcessorThreadMax 乘以处理器的数量，再乘以作为 ASP 宿主的进程的数量）。如果 Requests Executing 较高，Requests Queued 较大，并且 CPU 使用率低，则您可能需要增加 AspProcessorThreadMax。当启用时，线程门将设法优化 Requests Executing。
Active Server Pages\ Request Wait Time Active Server Pages\ Request Execution Time	Request Wait Time 表示最近的请求在队列中等待的时间（以毫秒为单位）。Request Execution Time 表示执行最近的请求所花的时间（以毫秒为单位）。用户的响应时间与 Request Wait Time 加上 Request Execution Time 加上网络等待时间成比例。
Active Server Pages\ Requests Queued	理想的情况下，Requests Queued 和 Request Wait 时间应接近于零，但它们会在不同的负载下时高时低。Requests Queued 的最大值由 AspRequestQueueMax 的配置数据库设置决定。如果到达极限，客户端浏览器将显示“HTTP 500/服务器太忙”。如果这些数字离预期的范围偏离太远，则您可能需要重写 ASP 应用程序以改善性能。

WWW 服务计数器

这些计数器将帮助您判断万维网发布服务（WWW 服务）处理通用网关接口 (CGI)、Internet 服务器 API (ISAPI)、Post，以及 Get 请求的状况。

计数器	描述
WWW serviceCGI Requests/sec WWW service\ ISAPI Extension Requests/Sec	这些计数器报告服务器处理 CGI 和 ISAPI 应用程序请求的速率。如果负载增大时这些值下降，您可能需要重新设计应用程序。注意 ASP 是 ISAPI 扩展并包括在第二个计数器中。
WWW service\ Get Requests/sec WWW service\ Post Requests/Sec	这些计数器反映了对服务器进行的这两种常见类型的 HTTP 请求的速率。Post 请求一般用于表单并发送到 ISAPI（包括 ASP）或 CGI。Get 请求构成了从浏览器发出的几乎所有其他请求，并包括对静态文件、ASP 和其他 ISAPI 的请求，以及 CGI 请求。

调整 Web 应用程序

本节不准备详细讨论调整 Web 应用程序的复杂方法，而是提供了改善应用程序性能的一般建议。在计划和测试 Web 应用程序时请考虑以下信息：

只要有可能，就使用托管代码（C# 或 Visual Basic .NET），Microsoft ASP.NET 或 ISAPI 应用程序。C# 和 Visual Basic .NET 应用程序比 ASP 应用程序运行速度快，因为运行时环境执行的是已编译的代码。所有这些类型的应用程序的运行速度都比相同的 CGI 应用程序快。
如果有可能，应避免应用程序中的托管代码向非托管代码的跳转。
只要有可能，应使用静态文件。静态文件不需要大量的内存或磁盘活动即可处理。
只要有可能，应最大限度地减少初始化处理。
应这样设计站点，以使应用程序向客户端推送处理负载。客户端处理可以避免网络延迟，节约服务器端资源，并可使更改立即显示给用户。一个常见的例子是添加客户端代码以验证表单是否填入了正确的数据，如检查电子邮件地址格式是否正确或者信用卡号码是否有正确的校验和。然而，服务器仍必须验证数据，因为恶意的客户端可能会发送格式不正确的数据。客户端检查可以减少往返次数并改善交互性。
要确保在成品服务器上关闭了 ASP 调试，并验证已将 AppAllowDebugging 配置数据库属性设置为 false。
只要有可能，为所有图像和 HTML 设置 expire 头，以使这些类型的文件存储在客户端的缓存中。
应避免在 ASP 应用程序或会话状态中存储单元线程组件，包括所有 Visual Basic 组件。Java 和大多数 C++ 对象都不包括在内。
只有在需要时才使用安全套接字层 (SSL)。使用 HTTPS 协议比标准的 HTTP 开销大得多。如果使用了 SSL，请确保被发送的信息（如信用卡号码或医疗信息）足够敏感以保证增加的性能开销。有关安全性调整问题的详细信息，请参阅性能和安全性。
应在工作进程隔离模式下运行 IIS，可以配置该模式以定期重新启动分配到应用程序池中的工作进程。回收工作进程可以最大限度地减少由于 Web 应用程序不完善而导致的一些问题。
建立 Web 园。Web 园是运行多个工作进程的应用程序池。
通过使用 Microsoft SQL Server™ 增强产品环境中的数据库驱动性能。一定要创建和维护优良的索引以最大限度地减少数据库查询上的 I/O。此外，应使用存储过程。存储过程的执行时间少得多，而且比用于执行相同任务的 ASP 脚本更容易编写。
作为一般规则，如果您有一个超过 100 行的 ASP 脚本（计算使用 #include 处理指令引入的文件中的代码行），应考虑创建 COM+ 组件来提供相同的功能。如果编写有效并且调试正常，COM+ 组件可以提供比相同的动态页面的脚本快 20 到 30 倍的处理速度。测量带有 #include 的 ASP 脚本大小的最简单的方法是，将页面的文件扩展名从 .asp 更改为 .stm，然后使用浏览器打开 .stm 文件。使用浏览器的“查看源文件”命令来显示 .asp 文件和被包括文件的代码行。
在将应用程序应用到站点之前，应首先对它们进行测试。如果产品 Web 服务器是一个多处理器系统，一定要在多处理器系统上进行压力测试，以便可以发现多处理器缩放问题以及脚本和组件中的竞争条件。Web 应用程序压力工具是进行这种压力测试的理想工具。有关详细信息，请参阅性能监视和可伸缩性工具。

相关主题

有关性能监视的详细信息，请参阅 Windows 帮助中的监视性能和解决性能问题。
有关配置应用程序以在 IIS 上运行的详细信息，包括有关应用程序隔离模式和配置 ASP 应用程序的信息，请参阅配置应用程序。
有关配置 IIS 作为应用程序宿主的信息，包括应用程序池、Web 园，以及 CPU 监视等功能，请参阅为应用程序配置服务器。
有关开发和使用 ASP.NET 和 ASP Web 应用程序的信息，请参阅 Web 应用程序指南。