正在阅读:性能大幅提升 全新出炉IIS7真实网站测试性能大幅提升 全新出炉IIS7真实网站测试

2008-02-29 10:13 出处:PConline原创 作者:老笨 责任编辑:huangjianjun
1测试场景回顶部

  

评测工程师简介
pcyangPConline
评测工程师:谢肖绵BLOG
  

    

  

 

 

  工程师点评:IIS7.0最大的改进还不是速度,而是模块化的结构,这与Windows Server2008 更完全的模块化设计吻合。目的无非是减少攻击面提高安全性,同时优化性能。

     在我们设计的场景里,我们侧重检查的是IIS对静态网页的吞吐效率。这是一个将千兆网络压榨到极限的测试场景。结果表明IIS7.0相比IIS6.0有显著的性能提升。 

  测试方法:在VMwareESX3.5上分别开两个完全一样的虚拟机,运行Windows2003 IIS6.0和Windows2008 IIS7.0,利用Loadrunner录制脚本并回放,模拟1000个并发用户打开13个静态网页,重复20次。用Loadrunner性能监视器分析性能差异。 

  IIS7开始页

  

  一、测试场景及脚本

  设置测试场景并没有费很大功夫,因为很久以来我们就想测试Web Server静态网页的性能。

  目前普遍存在的谬误就是很多人认为都Web2.0了,动态网页的性能才是最重要的。但是点开看看各大门户网站,例如新浪和太平洋这样全国范围的大门户网站,90%以上的内容还是绝对地址的静态页面。包括康盛科技这样著名的论坛软件,其实也一直在努力利用静态网页减轻数据库服务器的压力,同时起到优化搜索引擎表现的目的。

  毕竟在目前的互联网上,信息使用者还是要远远超过信息生产者。

  我们选择的测试网页,来源于一个真实的动漫网站。这位站长用一台单路双核、2G内存、两块SATA硬盘的服务器和100M独享带宽,支撑着日均200万的PV,高峰时间达到500万PV。测试之前这位站长因为持续的访问增长,正在苦恼是增加内存、硬盘还是增加带宽。测试之前我们就建议过这位站长,他的带宽不够了。因为按照太平洋对硬盘系统的测试,SATA硬盘的读写速度超过20MB/s,而100M带宽最多也就支持10MB/s的速度。测试的结果印证了我们的想法。由此也可以看出,Web服务器在利用带宽方面哪怕只有10-20%的提升,对小网站的经营者而言也是个了不起的改善。在广域网上,带宽的价格是远远超过服务器的。

2测试脚本回顶部

  IIS测试目录

  IIS测试目录

  IIS测试目录

  典型HTML文件

  IIS测试目录

  典型图片文件

  如上图,测试使用的网页是用离线浏览器器从真实的网站上下载,并直接复制到IIS服务器的 wwwroot目录下,其存放HTML的目录树从A-Z排列,每个字母下面又有数量不等的漫画主题,每个主题下又分若干卷。这样的目录结构使绝对地址变得很长,目录级树很多,但是无疑能提升文件系统的效率。

  最终的HTML文件都很小,平均不足10K,主要是页面都比较简洁,除了很少的文字外,是由一张大图(漫画)作为网页的主体。为了避免打广告的嫌疑,我们没有做网页截图。图像文件的目录采取跟HTML文件类似的目录结构,不过文件要大得多,平均大小超过180k。网站仅Z字头下面的文件数超过50000,大小为4G。全站的文件数超过百万,大小在100G上下。

  测试网站谈不上架设,IIS6.0和IIS7.0都是默认安装,直接将离线浏览器下载的网站镜像直接复制到wwwroot,连虚拟目录设置都省略了。

  接下来就是用Loadrunner录制、参数化、调试脚本。之前有网友在评论中质问我们懂不懂Loadrunner脚本。说懂或者不懂都不对,对LoadRunner这样一个上百万元许可费用的产品,谁也不能说全部懂。但是录制一个静态网页的测试脚本还不是什么“科技攻关”项目,其实多数网友都可以干,问题是你愿不愿花精力。

3测试环境回顶部

  二、测试脚本

  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个并发用户的负载,并不是一个轻松的活!

4测试数据解读回顶部

  三、测试环境

IIS7管理界面

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每秒点击

  IIS6每秒点击数

  IIS7每秒点击数

  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吞吐量

  IIS6吞吐量

  iis7吞吐量

  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每秒响应

  IIS6每秒响应

  iis7每秒响应

  IIS7每秒响应

  上面两张图是IIS7与IIS6每秒响应HTTP请求的数据。同样可以看出,IIS7相比IIS6 有27%的提升。需要解释的是,在HTTP类别里出现了三种,一个是著名的404,就是页面没有找到,这是因为离线浏览器还是没有完整的下载每个页面的所有元素。我们仔细分析过单个的404错误,发现没有下载的元素基本上是实际运行站点的小广告,因为有很多站外的链接,因此离线浏览器没有下载。另外一个就是503错误,也就是拒绝服务,原因如我们前面所说,这部分的数量是比较少的。从上图中也可以看出,代表503错误的曲线仅有一个尖峰后就一直很平坦,表明503错误仅在第一次循环中出现。我们选择代表IIS7和IIS6性能的数据是HTTP代码200的数据,也就是HTTP成功响应的数据。

  iis6每秒下载页面

  IIS6每秒下载页数

  iis7每秒下载页数

  IIS7每秒下载页数

  iis6每秒秒链接数

  IIS6每秒连接数

  iis7每秒连接数

  IIS7每秒连接数

  前面四个图分别是IIS7和IIS6每秒下载页数以及IIS7和IIS6每秒连接数。同前面结论一样,IIS7仍然领先于IIS6。每秒连接数的图比较有意思,每张图上都有开始的连接和结束的连接两个数据,这两个数据基本一致。因为测试脚本每个连接处理的时间较短,因此看起来是每周期同时开始了新连接,也结束了旧连接。同样,IIS7每秒连接数要好于IIS6。领先的幅度也是同前面接近的26%。

8结论回顶部

  iis6缓冲时间

  IIS6

  IIS7时间

  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确实值得期待。当然,服务器操作系统的升级远远不只是一个技术决策,更多的是商业决策。但是不管怎么说人到中年后的微软仍然保持着强大的活力。

  

为您推荐

加载更多
加载更多
加载更多
加载更多
加载更多
加载更多
加载更多
加载更多
加载更多

服务器论坛帖子排行

最高点击 最高回复 最新
最新资讯离线随时看 聊天吐槽赢奖品