Internet Information Services 5.0 的性能（转）

Windows 2000 中包含的 Internet Information Services (IIS) 5.0 对 IIS 4.0 高性能 Web 服务器进行了重大改进。使用 IIS 4.0，Internet 服务提供商 (ISP) 提出了这样的问题：“在一台服务器上，我可以有效地运行多少个 Web 站点？” 在与我们的 ISP 客户交谈后，我们发现答案是：单个 IIS 4.0 服务器可以支持大约 250 个 Web 站点，而对于需要在一台服务器上提供数千个站点的 ISP 客户，这样的性能难以满足要求。IIS 小组在 IIS 5.0 中解决了这个问题，并在提供的方案中大大改进了 IIS 的性能。现在，可以在一台服务器上运行数千个站点。使用 IIS 5.0 解决了 IIS 4.0 的问题后，又提出了新的问题：“该服务器预计能处理多少负载？” IIS 5.0 服务器可提供的站点数量与预计负载直接成比例。

预计负载等于每秒对单个服务器的预计请求数，并受内容类型的影响，这里的内容类型是指动态页面与静态页面的比例。最近几年，人们发布的 Web 内容趋于动态化，所以必须重新考虑性能要求。针对这一趋势，我们设计了一个测试，来分析 ISP 设置下 IIS 5.0 服务器上运行的动态和静态页面的性能，在测试中，动态内容是使用 ASP 脚本和 Perl 脚本开发的。

测试

我们设计该测试，来分析 ISP 设置中 IIS 5.0 的性能。我们创建了包含动态和静态内容的 Web 站点，确定服务器每秒能够处理的请求数。随着站点数的增加，对性能的影响被测量出来。

将如下硬件用作 Web 服务器：

DELL PowerEdge 6350 Enterprise Server（4 个 Xeon III 550 MHz 处理器、4 G RAM、100 MB 的 Ethernet NIC）
通过 FiberChannel 连接的 DELL 850F 外部磁盘阵列。
我们遵循“Windows 2000 性能调试和基准”白皮书中给出的有关性能方面的建议。磁盘阵列不通过任何硬件 RAID 架构连接，而是为每个磁盘分配一个驱动器号，并将 Web 站点的内容平均分布在各个磁盘中。我们使用了 Windows 2000 启动选项“NumProcs”和“MaxMem”，来显示当处理数千个站点时 RAM 和 CPU 数量的影响。

我们创建了大量文件来模仿 ISP 设置，IIS 5.0 静态文件缓存成为一个可能的性能障碍：尽管几乎未收到请求，也消耗了资源。所以，我设计了两种测试方案：

IIS 静态文件缓存打开
IIS 静态文件缓存关闭
由于请求被平均分布在所有站点上，所以我们使用了“DisableMemCache”全局注册表设置，来禁用 IIS 静态文件缓存。（可能也已使用“NoCache”配置数据库属性。）

测试分为三个阶段。首先，创建包含 1010 个文件的 5000 个站点：其中，910 个静态文件和 100 个动态文件。每个站点包含如下静态内容： 文件大小（字节）
文件数

500,000

10

250,000

10

100,000

20

50,000

50

25,000

150

10,000

260

5,000

310

1,000

100

这样，每个站点总计有 20,000,000 字节。动态文件分为两种脚本方法，分布如下：

在 ASP 页中 50 个 VBScript
使用 ActiveState Perl for ISAPI 的 50 个 Perl 脚本。
对于每种语言，这些动态页中 5 页是 Guest Book 应用程序，其它 45 页仅解析查询字符串并输出静态文本。每个动态页输出大约 1 KB 内容。所有脚本均在此新的“共用”应用程序中提供，因为我们认识到，使用这种方法，Web 服务提供商可获得更高的 Web 服务器可靠性。

其次，一开始我们将负载加到 250 个站点上，然后以 250 个站点递增，直到到达总计 5,000 个站点。加载的工作使用 WebCAT 加载工具来完成。WebCAT 配置为拥有 180 个到 Web 服务器的并发连接，连接之间没有延迟。请求分布如下：

所有请求的 70% 指向静态内容
所有请求的 30% 指向动态内容（ASP 或 Perl）。
同时，在每个站点内，所有请求的 90% 指向 10% 的文件，这样，在每个 Web 站点内，91 个静态文件和 5 个动态文件接收了 90% 的请求。

结果

客户已经在关注 ASP 编程模型 IIS 4.0 实现的可扩展性。尽管动态数据对 CPU 的影响始终比静态数据大，但从下面的图表显示，即使当数万个 ASP 脚本与静态数据一起使用时，性能依然很好。由于这些曲线图是根据每秒的请求数产生的，所以必须注意每 100 个请求包含大约 1.2 MB 数据。曲线图的线条代表了在该测试中使用的不同处理器和 RAM 配置。

前两个图表给出的是使用基于 ASP 动态内容所产生的结果。第一个图表中，可以看出随着站点数的增加，增加 CPU 的数目对性能几乎没有影响。尽管随着站点数的增加性能下降，但 IIS 5.0 仍然可以每秒输出 5 MB 信息。

如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

在下一个图表中，我们再次看到类似的趋势。在站点数较少的情况下，增加更多的 CPU 可使性能明显提高，但在有大量站点的情况下，性能提高较少。

如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

对比上面两个图表可以发现，静态文件缓存设置不当会影响性能。在站点数不多的情况下，CPU 数量决定了性能的高低。随着站点数增加，性能将与 CPU 数量和可用内存数量紧密相关。当 CPU 容量与可用内存数量不匹配时，性能就会降低。虽然这里没有显示，但正确调试的缓存（仅对经常点击的站点进行缓存）预计能够提高性能。

下面两个图表显示使用基于 Perl 的动态内容所得到的性能结果。结果再次证明，CPU 的数量是影响性能的重要因素，所以，只显示了 4 G RAM 配置。应当注意，在这两个图表中，我们看见数据点接近每秒 900 个请求（大约每秒 10 MB 数据），此时，负载增加必须增加相应的网络处理能力。

第一个 Perl 图表清楚地表明，在站点数较少的情况下，少量增加 CPU 就会显著影响总体性能。我们还可以看到，使 CPU 能力与内存数量相匹配会多么显著地提高性能。

如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

在下面的图表中，我们再次看见 4 CPU-4 G 内存配置要比其它配置的性能好得多。

如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

Perl 图表表明，当您有足够的 CPU 容量并且提供较少站点时，调整静态文件缓存会对性能产生积极的影响。但是，随着站点数的增加，我们看见增加缓存不足以继续提供极高的性能。

结论

结果表明，使用 IIS 5.0，一个 Web 服务器提供的站点远多于 IIS 4.0 的限制（250 个）。尽管每个图表都显示随着站点数量的增加性能将会下降，但大多数硬件配置可以提供 5,000 个 Web 站点并每天处理超过 1,700 万个请求（使用 4 CPU-4 G 内存配置，每天处理 3,080-4,620 万个请求）。我们看到，在单个服务器上创建的站点数量不是性能的限制因素，实际上，限制因素是接收负载的站点数。当提供少量站点时，站点性能和 CPU 数量之间存在着不可否认的关联。但是，当提供大量站点时，这种关系就不太明显，并会受到 RAM 的影响。而且，如果设置不当，IIS 5.0 静态文件缓存就会影响性能，但是，正确的设置（甚至通过删除进行的调整）则会提高 Web 服务器的性能。

对这四个图表进行比较，结果表明，Perl for ISAPI 的性能与 ASP 的性能在同等水平上。由于在 IIS 4.0 CGI 进程模型下测试 Perl 时性能较差，普遍认为 Perl 是非 IIS 兼容的脚本语言。随着引入了 IIS 5.0 和 ActiveState Perl for ISAPI，客户可以方便地将现有的 Perl 脚本从其它平台移植过来，使之运行在 IIS/Windows 2000 平台上。使用 ActiveState Perl for ISAPI，IIS 5.0 用户可获得与 ASP 应用程序相同的高性能。

其它资源

IIS 调试指南： http://www.microsoft.com/windows2000/library/operations/web/tuning.asp
IIS 5.0 技术概述： http://www.microsoft.com/windows2000/library/howitworks/iis/iis5techoverview.asp
Windows 2000 Web 和应用程序服务： http://www.microsoft.com/windows2000/guide/server/features/appsvcs.asp
ActiveState Web 站点： http://www.ActiveState.com/
DELL Web 站点： http://www.DELL.com/

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10294527/viewspace-124557/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10294527/viewspace-124557/