原文出自太平洋电脑网Pconline-[企业频道]:http://smb.pconline.com.cn/0802/1230982.html
工程师点评：IIS7.0最大的改进还不是速度，而是模块化的结构，这与Windows Server2008 更完全的模块化设计吻合。目的无非是减少攻击面提高安全性，同时优化性能。
在我们设计的场景里，我们侧重检查的是IIS对静态网页的吞吐效率。这是一个将千兆网络压榨到极限的测试场景。结果表明IIS7.0相比IIS6.0有显著的性能提升。
测试方法：在VMwareESX3.5上分别开两个完全一样的虚拟机，运行Windows2003 IIS6.0和Windows2008 IIS7.0，利用Loadrunner录制脚本并回放，模拟1000个并发用户打开13个静态网页，重复20次。用Loadrunner性能监视器分析性能差异。
一、测试场景及脚本
设置测试场景并没有费很大功夫，因为很久以来我们就想测试Web Server静态网页的性能。
目前普遍存在的谬误就是很多人认为都Web2.0了，动态网页的性能才是最重要的。但是点开看看各大门户网站，例如新浪和太平洋这样全国范围的大门户网站，90%以上的内容还是绝对地址的静态页面。包括康盛科技这样著名的论坛软件，其实也一直在努力利用静态网页减轻数据库服务器的压力，同时起到优化搜索引擎表现的目的。
毕竟在目前的互联网上，信息使用者还是要远远超过信息生产者。
我们选择的测试网页，来源于一个真实的动漫网站。这位站长用一台单路双核、2G内存、两块SATA硬盘的服务器和100M独享带宽，支撑着日均200万的PV，高峰时间达到500万PV。测试之前这位站长因为持续的访问增长，正在苦恼是增加内存、硬盘还是增加带宽。测试之前我们就建议过这位站长，他的带宽不够了。因为按照太平洋对硬盘系统的测试，SATA硬盘的读写速度超过20MB/s，而100M带宽最多也就支持10MB/s的速度。测试的结果印证了我们的想法。由此也可以看出，Web服务器在利用带宽方面哪怕只有10-20%的提升，对小网站的经营者而言也是个了不起的改善。在广域网上，带宽的价格是远远超过服务器的。
IIS测试目录
典型HTML文件
典型图片文件
如上图，测试使用的网页是用离线浏览器器从真实的网站上下载，并直接复制到IIS服务器的 wwwroot目录下，其存放HTML的目录树从A-Z排列，每个字母下面又有数量不等的漫画主题，每个主题下又分若干卷。这样的目录结构使绝对地址变得很长，目录级树很多，但是无疑能提升文件系统的效率。
最终的HTML文件都很小，平均不足10K，主要是页面都比较简洁，除了很少的文字外，是由一张大图（漫画）作为网页的主体。为了避免打广告的嫌疑，我们没有做网页截图。图像文件的目录采取跟HTML文件类似的目录结构，不过文件要大得多，平均大小超过180k。网站仅Z字头下面的文件数超过50000，大小为4G。全站的文件数超过百万，大小在100G上下。
测试网站谈不上架设，IIS6.0和IIS7.0都是默认安装，直接将离线浏览器下载的网站镜像直接复制到wwwroot，连虚拟目录设置都省略了。
接下来就是用Loadrunner录制、参数化、调试脚本。之前有网友在评论中质问我们懂不懂Loadrunner脚本。说懂或者不懂都不对，对LoadRunner这样一个上百万元许可费用的产品，谁也不能说全部懂。但是录制一个静态网页的测试脚本还不是什么“科技攻关”项目，其实多数网友都可以干，问题是你愿不愿花精力。
二、测试脚本
Loadrunner脚本录制参数化
脚本比较简单，主体部分类似这个：
lr_rendezvous("begin");
web_url("index.html",
"URL=http://10.0.20.2/html/{path}/index.html",
"Resource=0",
"RecContentType=text/html",
"Referer=http://10.0.20.2/ggyy8/www.ggyy8.cn/html/Z/",
"Snapshot=t2.inf",
"Mode=HTML",
EXTRARES,
"Url=/images/bg.jpg", ENDITEM,
LAST);
脚本的第一行是插入集合点，作用就是让所有测试虚拟用户在这个点集中，同时向服务器发起请求。这样能保证虚拟用户的并发性。web_url这一句的意思相当于用IE打开一个链接：http://10.0.20.2/html/{path}/index.html。其中的PATH是参数化内容，在众多虚拟用户并发时，这个参数会变化，如果没有一点变化，相当于服务器将一个动作重复了1000次。参数化可以让不同虚拟用户访问不同文件，再现实际访问场景。
在本的事务部分，也就是一直参与循环执行的部分，总共有13个类似的web_url，每个web_url都进行了参数化。但是并不是所有虚拟用户每次访问都是不同文件，如果脚本这样参数化，估计就成了测试Windows2003和Windows2008文件系统的性能。实际上我们在SMB（服务器消息块，微软文件共享协议）测试中就发现，不论是微软的Hyper-v还是VMware的虚拟文件系统相比物理系统，有很大的性能损失（写的性能至少损失50%以上）。在实际测试中，我们发现即便是很多内容从IIS缓存中读取，还是会遇到拒绝服务的现象。千兆网1000个并发用户的负载，并不是一个轻松的活！
三、测试环境
IIS7全新管理界面
录制并调试好脚本，就进入测试环节。实际的测试环境就像我们开始所说，服务器是在星盈的物理机上安装了VMware ESX3.5构成虚拟平台，物理服务器是两路四核，双千兆网卡，16G内存，硬盘是4*143GSAS组成的RAID6。运行64位Windows2003和Windows2008的虚拟机都是设置了2G的内存上限，一个虚拟CPU，限制CPU的性能为4096M，是完全一致的虚拟机环境。
客户机也就是Loadrunner运行的机器采用浪潮280D，配置两路四核45nm Intel5410至强处理器，8G内存，存储系统是3*73GSAS组成RAID5，客户机操作系统为32位Windows2003。网络环境是全千兆交换机环境。
测试时服务器上同时运行了两个虚拟机，其中一个在测试IIS6时运行64位Windows2003，测试IIS7时运行64位Windows2008，另一个虚拟机是进行Windows2008NAP测试时建立的主域控制器。测试时为了避免网络环境影响，在主域控制器这台虚拟机上没有进行任何操作。保证IIS6和IIS7在一个完全平等的环境下进行测试。为了避免修改脚本的麻烦，我们将作为服务器的Windows2003和Windows2008IP地址同样设置为10.0.20.2。
对IIS6以及IIS7，我们每个测试脚本都运行两次，设置1000个并发虚拟用户，循环执行20次。测试中我们也发现，当操作系统启动后进行第一测试，往往会在第一个循环时发生拒绝服务器的现象，不论是IIS6还是IIS7都有这种现象。我们为了避免虚拟机的影响，又在另一台华硕物理服务器上进行了类似测试，结果发现同样在第一轮测试时发生了拒绝服务。差别是IIS6发生拒绝服务的数量更大，而IIS7和物理机发生拒绝服务的数量相对少些。排除了虚拟机因素的影响。
四、测试数据
IIS6每秒点击数
IIS7每秒点击数
以上两图是Loadrunner统计的每秒点击次数。可以发现，IIS7的点击次数是2362次/秒，而IIS6的点击次数是1856次/秒。IIS7相对IIS6有27%的性能提升。从图中可以看出，两个点击次数的图形都呈现比较规则的锯齿状，这是因为每个测试循环完成的测试内容是相近的，而各自幅度的差异是因为每次测试下载的页面并不相同，因此页面大小方面会有差异。这种锯齿状的图形在后面很多测试数据中都可以看到。
其实仅从每秒点击数一个数据就可以发现，IIS7的性能确实比IIS6有显著提升。27%这个数据虽然不如微软工程师测试的近50%左右来得夸张，但是IIS6也是微软一个成熟的产品，在这种情况下还能取得很大幅度的提升，跟Windows2008TCP/IP协议栈的重写，以及Windows2008整体性能的提升有很大关系。实际上关于网络性能微软有一个更夸张的测试，结论是Windows2008相比Windows2003广域网络性能有40多倍的提升。在周六休息时间，我们利用太平洋电脑网北京和广州的VPN线路进行过类似的广域网测试，测试的结果是Windows2008相比Windows2003广域网性能有3倍的提升，可以说是相当显著。
IIS6吞吐量
IIS7吞吐量
从上两图IIS7和IIS6的吞吐量来看，IIS7相比IIS6 也有22%左右的提升。其中IIS7的吞吐量接近93MB/s，基本上是千兆网的上限，而IIS6的吞吐量也接近76MB/s。测试中我们也检测过CPU、内存和网络带宽的占用情况。除网络在高峰期有93%以上的利用率，CPU的占用并不高。要知道物理机总共有8个核心，每个核心的频率都是2G，4096M的CPU上限限制，不过相当于一个双核处理器。当然，实际网络使用环境CPU的占用会更高一些，原因是实际环境文件访问更分散一些。综合考虑，作为Web服务器，CPU的能力是最容易得到，一个四核CPU不过2000多元，内存也相对容易提升，存储系统的成本也不会太高。但是带宽的费用是长期持续，费用最高，带宽利用率高的软件系统对运营类的网站成本改善，有很高的价值。
IIS6每秒响应
IIS7每秒响应
上面两张图是IIS7与IIS6每秒响应HTTP请求的数据。同样可以看出，IIS7相比IIS6 有27%的提升。需要解释的是，在HTTP类别里出现了三种，一个是著名的404，就是页面没有找到，这是因为离线浏览器还是没有完整的下载每个页面的所有元素。我们仔细分析过单个的404错误，发现没有下载的元素基本上是实际运行站点的小广告，因为有很多站外的链接，因此离线浏览器没有下载。另外一个就是503错误，也就是拒绝服务，原因如我们前面所说，这部分的数量是比较少的。从上图中也可以看出，代表503错误的曲线仅有一个尖峰后就一直很平坦，表明503错误仅在第一次循环中出现。我们选择代表IIS7和IIS6性能的数据是HTTP代码200的数据，也就是HTTP成功响应的数据。
IIS6每秒下载页数
IIS7每秒下载页数
IIS6每秒连接数
IIS7每秒连接数
前面四个图分别是IIS7和IIS6每秒下载页数以及IIS7和IIS6每秒连接数。同前面结论一样，IIS7仍然领先于IIS6。每秒连接数的图比较有意思，每张图上都有开始的连接和结束的连接两个数据，这两个数据基本一致。因为测试脚本每个连接处理的时间较短，因此看起来是每周期同时开始了新连接，也结束了旧连接。同样，IIS7每秒连接数要好于IIS6。领先的幅度也是同前面接近的26%。
IIS6
IIS7
上面两张图分别是IIS7和IIS6下载时间。由于每个页面构成元素差异，页面大小也不相同，因此每个页面下载的时间有差异，这不是问题的关键。这两张图最有意思的地方在下面的平均时间，Loadrunner将时间细分成了网络时间和服务器时间，iis7和iis6的网络时间有小幅度差异，这很正常，因为都是千兆网络环境。但是服务器时间差别巨大，IIS7的平均服务器时间是0.033，IIS6的平均服务器时间是0.067。因为网络消耗时间要比服务器时间高一个数量级，整体上IIS7相比IIS6的性能优势不是十分明显。但是单独对比服务器时间，可以看出IIS7是IIS6耗时的一半。这就意味着在消耗服务器时间比较多的应用中，IIS7性能完全可能超过IIS6的50%。这同样是一个惊人的数字。可见软件的优化对性能的影响是至关重要的。也可以看出IIS 7性能的潜力。
五、结论
如果跳过冗长的测试场景设计和测试数据分析，您需要知道的一个结论是在静态网页这个测试场景中，IIS7相比IIS6有接近30%的性能提升。
距离Windows2003的发布已经5年，而Windows2008的开发是在2003年前就开始。微软耗时5年以上，投资数十亿美元研发的新一代服务器操作系统Windows Server2008已经正是发布，从我们测试的情况看，2008确实值得期待。当然，服务器操作系统的升级远远不只是一个技术决策，更多的是商业决策。但是不管怎么说人到中年后的微软仍然保持着强大的活力。