IIS 7.0: 使用集成的ASP.NET管道增强应用程序
| >
在刷新 http://myphpgallery/ 上的 Qdig 页面并登录后，页面上 的所有超链接已更换为使用友好的 URL（请参见图 8）。到目前为止，我并不需要更改原始应用程序的任 何一行代码，只是使用 ASP.NET 的现有功能和针对 ASP.NET 集成管道开发的新功能对原始程序的功能进 行了一些重要升级。
Figure 8 The Revised Gallery with Friendly URLs 测试性能 至此，虽然我没有更改 Qdig 的任何源代码，但我向该应用程序添加了诸多功能。所 有这些新功能对应用程序的性能有多大影响呢？由于 Windows 上 CGI 机制的进程启动开销，性能历来是 IIS 平台上 PHP 应用程序的重要问题。通过消除此开销，FastCGI 有望显著改进应用程序的性能，从而 使 IIS 成为承载 PHP 和其他 FastCGI 兼容的应用程序的更具吸引力的平台。然而，如果我刚才引入的 应用程序增强又使此类开销攀升回去的话，那么，考虑在 IIS 上部署 PHP 应用程序便不会有如此大的吸 引力。 不过，我添加的功能增强对 Qdig 的性能其实影响很小。图 9 显示了我对该应用程序执行的性能测试 的概要。 Figure 9 Performance Results 测试 |
每秒请求数（越多越好） |
使用 CGI 的 Qdig
32
使用 FastCGI 的 Qdig
93
使用 FastCGI 的 Qdig 和友好的 URL
88
使用 CGI 的 Hello.php
51
使用 FastCGI 的 Hello.php
2239
测试采用 Microsoft Web Capacity Analysis Tool (WCAT) 6.3 执行，服务器上 CPU 利用率达到满 负荷，同时运行了 100 个虚拟客户端，请求了图库内的一系列 Qdig URL。最后的测试使用了友好的 URL 取代 Qdig URL，以便利用转换功能。为了方便测试，禁用了身份验证。 您可以看到，从 CGI 转移到 FastCGI，吞吐量几乎提高了三倍。在添加两个友好 URL 模块后，吞吐 量只下降了 5%，我看这微不足道。 遗憾的是，Qdig 与 CPU 性能联系紧密，因此不可能获得由 FastCGI 提供的大幅度性能提升。相比而 言，对于简单的 hello.php 脚本，当从 CGI 转移到 FastCGI 时，我看到吞吐量提高了 43 倍。即使在 添加响应筛选器（一项代价很高的操作）之后，对总吞吐量的影响与应用程序自身的开销相比也是微不足 道的。 只要涉及服务器性能调优，这种情形就变得相当糟糕，因为除了应用程序改进自身性能以外，您也无 能为力。除非您是应用程序的开发者，否则，更改应用程序自身的代码通常是不可能的，况且也很难更改 。对于我来说当然不予考虑，因为我一开始就决定不修改应用程序本身。 ASP.NET 输出缓存 输出缓存是 ASP.NET 中的一项功能，利用此功能，对相同资源的后续请求可以重用 Web 应用程序所 产生的响应。实际上，ASP.NET 提供了一组非常丰富的缓存功能，利用其缓存 API 可以缓存 ASP.NET 应 用程序的内部数据，利用输出缓存则可以缓存应用程序的整个响应。这两种功能通常可以增强应用程序的 性能，并显著降低后端资源的负载。IIS 7.0 中的新增功能可以让非 ASP.NET 内容类型使用 ASP.NET 输 出缓存，这正是我要使用的功能，以便为图库带来一些性能提升。 应用程序性能调优比较琐碎，通常需要大量的编码工作，成块地消除应用程序的处理开销，相对而言 ，输出缓存则倾向于按一定比例彻底消除请求负载的整体开销。其有效性取决于应用程序的使用位置：应 用程序的用户请求访问相同内容的频率。对于典型的应用程序而言，通常适用 90/10 规则，其基本含义 是：90％ 的请求总是对应 10％ 的内容。如果您能将这 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
