FGOGSHM0909WebLogic与JBoss浏览页面压力测试报告.doc

WebLogic与JBoss浏览页面压力测试报告版本 修订历史记录日期版本说明作者目录1.环境要求51.1硬件环境：51.2软件环境：52.内容52.1不限定页面响应时间的网页浏览(有图片)52.1.1JBoss3.2.1:Summary ReportWindows Resources.1Memory:.2CPU.3网络带宽.4磁盘数据库页面分解122.1.2WebLogic8.1:Summary ReportWindows Resources.1Memory:.2CPU.3网络带宽.4磁盘数据库页面分解222.2限定页面响应时间的网页浏览(有图片)242.2.1JBoss3.2.1:Summary ReportWindows Resources2.1Memory:2.2CPU2.3网络带宽2.4磁盘2数据库30页面分解312.2.2WebLogic8.1:3Summary Report3Windows Resources3.1Memory:3.2CPU3.3网络带宽3.4磁盘3数据库3页面分解402.3限定页面响应时间的网页浏览(无图片)422.3.1JBoss3.2.1:4Summary Report4Windows Resources4.1Memory:4.2CPU4.3网络带宽4.4磁盘4数据库4页面分解49WebLogic与JBoss浏览页面压力测试分析报告1. 环境要求1.1 硬件环境：测试客户机(3台)：处理器：Celeron 1.7GHz CPU，内存：Kingston 512M，硬盘：Maxtor 40G测试服务器(2台)：数据库服务器：处理器：XEON 2.4GHz 400FSB 双路CPU以上的配置，内存：Kingston 2*512M D266 ECC，硬盘：IBM 2*18.4 SCSIWEB服务器：处理器：Celeron 1.7GHz CPU，内存：Kingston 512M，硬盘：Maxtor 40G1.2 软件环境：服务器：Windows2000 Advanced Server 客户机： Windows2000，IE6.0数据库：Oracle 9iWEB Server服务平台： Jboss3.2.1和WebLogic8.12. 内容2.1 不限定页面响应时间的网页浏览(有图片)需求明确指定：在线用户数要达到10万2.1.1 JBoss3.2.1:用例脚本：浏览客户服务首页面janescriptsJBOSS包含图片URLServicePage浏览首页janescriptsJBOSS包含图片URLFrontPage运行场景(scenario)：5,000Vusers,start at same time with 10 different IPs，NewsPage5,000Vusers,start at same time with 20 different IPs，FrontPage监控参数：Windows Resources(Memory , CPU , Network Interface)，Oracle()结果分析： Summary Report最大同时运行虚拟用户达到214个，首页最小响应时间为0.688s，最大响应时间为53.328s，平均响应时间为22.144s，90%响应时间在30.537s左右，通过3116个，失败1703个，通过率达到62%；客户服务首页最小响应时间为0.141s，最大响应时间为27.156s，平均响应时间为5.862s，90%响应时间在11.694s左右，通过1421个，失败3579个，通过率达到28%； Windows Resources.1 Memory:根据这两张图表的显示，WEB SERVER的内存消耗较为平稳，有效内存并没有随着用户量的增加而起较大波动，一直维持在198270Mbytes之间，与WEB SERVER的512Mbytes相比，平均所占比例为40%左右，可见内存仍有空闲，出现了一部分的页面错误，页面硬错误很少，大多数为页面软错误，不会造成WEB页面延迟的。因此内存未成为系统的瓶颈。.2 CPU通过图表很明显地看出系统CPU资源随着同时运行用户数的大小进行着，由于目前采用的是单CPU的普通PC机，运行脚本时，CPU的处理量大多在93%100%，达到满负荷了；进程队列数也高，平均9.683个，最大的达到18个，这和单CPU有很大的关系，如果采用多CPU的服务器，状况可能会更好；页面切换指标显示在19905495之间，平均值仅为2638，说明CPU资源未过多用于切换线程消耗，主要还是用在处理脚本上。因此，在此运行状态下CPU未成为系统瓶颈。.3 网络带宽网络带宽监控曲线只有在最后时刻有了较大的波动，在大多数时间内并没有随着用户数的增加而起波动，因此判定此波动可能是有电脑通过内部局域网直接访问该WEB SERVER的文件夹，不是平台的客户端浏览器造成，因此判断带宽未对WEB服务器造成影响。.4 磁盘从CPU、磁盘、网络三者相比较，CPU跟随用户数量的起伏最大，但只有偶尔到达过100%，同时磁盘与网络的参数起伏较小，因此相比较而言，目前硬件系统未成为WEB SERVER的瓶颈。 数据库在此场景中数据库仅受到WEB SERVER的查询与读取的访问，因此数据库相应参数曲线显示较为的稳定，无大幅度的波动。 页面分解FrontPage:页面图片分解显示，一个页面中包含了大量的图片元素，造成在页面下载过程中页面响应速度缓慢，尤其是http:/fgogtest/frontend/reloadPage.js,此元素只有1.699Kbytes大小，在页面响应时间中是等待最长达到1.296second，根据页面元素分解，主要的时间消耗在联接服务器上，第一次缓存的时间相应比较少，这说明WEB SERVER是目前平台系统的瓶颈，也是影响客户端响应时间的关键。ServicePage:页面图片分解显示，一个页面中包含了大量的图片元素，造成在页面下载过程中页面响应速度缓慢，尤其是http:/fgogtest/frontend/reloadPage.js ,此元素只有1.699Kbytes大小，在页面响应时间中是等待最长达到0.579second，根据页面元素分解，主要的时间消耗在联接服务器上，第一次缓存的时间相应比较少，这说明WEB SERVER是目前平台系统的瓶颈，也是影响客户端响应时间的关键。2.1.2 WebLogic8.1:用例脚本：浏览客户服务首页面janescriptsWebLogic包含图片URLServicePage浏览首页janescriptsWebLogic包含图片URLFrontPage运行场景(scenario)：5,000Vusers,start at same time with 10 different IPs，NewsPage5,000Vusers,start at same time with 20 different IPs，FrontPage监控参数：Windows Resources(Memory , CPU , Network Interface)，Oracle()结果分析： Summary Report最大同时运行虚拟用户达到1839个，首页最小响应时间为0.219s，最大响应时间为168.297s，平均响应时间为90.67s，90%响应时间在146.935s左右，通过4483个，失败428个，通过率达到90%；客户服务首页最小响应时间为0.891s，最大响应时间为114.719s，平均响应时间为61.316s，90%响应时间在104.882s左右，通过4723个，失败277个，通过率达到94%； Windows Resources.1 Memory:根据这两张图表的显示，WEB SERVER运行初期内存消耗较为平稳，在达到同时运行1839个用户时，有效内存开始下降，在整个测试过程中有效内存一直维持在129271Mbytes之间，与WEB SERVER的512Mbytes相比，平均值所占比例为31%左右，可见内存还有空余，页面错误发生较多平均要达到117/sec，其中页面硬错误出现较少，平均只有0.105/sec,大多是页面软错误，因此不会造成WEB页面延迟的。.2 CPU通过图表很明显地看出系统CPU资源随着同时运行用户数的大小进行着，由于目前采用的是单CPU的普通PC机，运行脚本时，CPU的处理量大多在72%100%，几乎已经是满负荷了；进程队列数也较高，平均5.341个，最大的达到17个，这和单CPU有很大的关系，如果采用多CPU的服务器，状况就可能好转；页面切换指标显示在22596526之间，平均值达到4424，说明CPU用于切换线程资源消耗还不算过多，主要还是在处理脚本，但可以判断目前硬件系统的瓶颈在CPU上。.3 网络带宽网络带宽没有随着用户数的增加而起波动，因此判定带宽还未对WEB服务器造成影响。.4 磁盘从CPU、磁盘、网络三者相比较，CPU跟随用户数量的起伏最大，很多时候甚至到达了100%，相反的磁盘与网络的参数起伏较小，因此相比较而言，CPU是目前系统的瓶颈。 数据库在此场景中数据库受到WEB SERVER的查询访问，因此数据库监控参数中的当前打开游标参数的曲线显示为不断向上增加，理论上应该是访问页面的用户数增减，当前打开游标的参数同步或有一些滞后地跟着增减，但奇怪的是该曲线并未按运行用户的曲线同步波动，也就可能意味着WEB SERVER对数据库的查询结束后并未释放数据库的游标(有待进一步的验证)。 页面分解页面图片分解显示，一个页面中包含了大量的图片元素，造成在页面下载过程中页面响应速度缓慢，这些页面元素分别的下载速度较为平均，均在3秒左右，显示WEB SERVER较为稳定，但网络响应时间过长，大多数的时间是消耗在第一次缓存上的。除客户端第一次访问页面外，浏览器对于再次登录平台访问页面的默认设置中有客户端缓存，再次访问平台页面的响应时间可以扣除第一次缓存所消耗的时间。因此从理论上来说，在过了初期的页面浏览与注册的高峰期后，正常运营期内客户端页面响应时间可以减少大部分，同时支持的用户数应该可以成倍增加，也就意味着同样的在线容量所需的支持服务器数量可减少较多的数量。2.2 限定页面响应时间的网页浏览(有图片)通常用户玩家浏览网页所能忍受的响应时间5秒，极限能忍受的响应时间为10秒，超过10秒用户玩家将不会有耐心等下去，因此在此测试场景下，进行测试JBoss和WebLogic在限定响应时间内能支持浏览页面的用户数。2.2.1 JBoss3.2.1:用例脚本：浏览首页janescriptsJBOSS包含图片URLFrontPage运行场景(scenario)：start at same time with 20 different IPs，FrontPage监控参数：Windows Resources(Memory , CPU , Network Interface),Oracle()结果分析：VUsersTRT20-5050-100100-5005SecondPassed:506,Failed:0Average Response Time:5.04sMaximum Running Vusers:20Duration: 02:21(mm:ss)Passed:450,Failed:0Average Response Time:13.916sMaximum Running Vusers:50Duration: 02:29(mm:ss)Passed:824,Failed:42Average Response Time:19.854sMaximum Running Vusers:100Duration: 04:11(mm:ss)10SecondPassed:459,Failed:0Average Response Time:4.9sMaximum Running Vusers:20Duration: 02:04(mm:ss)Passed:1,074,Failed:0Average Response Time:11.137sMaximum Running Vusers:50Duration: 04:16(mm:ss)Passed: 1,086,Failed: 133Average Response Time: 17.768sMaximum Running Vusers:100Duration: 04:38(mm:ss)比较6组测试结果，以50-100VUsers，10Second这个测试结果较为合理，有一定的参考价值。 Summary Report此测试的环境为设定测试目标的环境，在此测试运行环境情况下，最大同时运行虚拟用户达到50个，最小响应时间为5.906s，最大响应时间为12.688s，平均响应时间为11.137s，90%响应时间在11.761s左右，通过1,074个，失败0个。 Windows Resources.1 Memory:根据这两张图表的显示，WEB SERVER的内存消耗较为平稳，有效内存并没有随着用户量的增加而起较大波动，一直维持在178179Mbytes之间，与WEB SERVER的512Mbytes相比，平均所占比例为35%左右，可见内存仍有空闲，出现了一部分的页面错误，少部分是页面硬错误，需要重新从磁盘读取，会影响客户端响应速度，但大多数为页面软错误，不会造成WEB页面延迟的。因此内存未成为系统的瓶颈。.2 CPU通过图表很明显地看出系统CPU资源随着同时运行用户数的大小进行着，由于目前采用的是单CPU的普通PC机，运行脚本时，CPU的处理量大多在93%100%，达到系统的满负荷了；进程队列数较高，平均11.892个，最大的达到18个，这和单CPU有很大的关系，如果采用多CPU的服务器，状况可能会更好；页面切换指标显示在21685146之间，平均值仅为2821，说明切换线程未过多消耗CPU资源，主要还是处理脚本上运用的。因此，在此运行状态下CPU成为系统瓶颈。.3 网络带宽网络带宽没有随着用户数的增加而起波动，因此判定带宽还未对WEB服务器造成影响。.4 磁盘从CPU、磁盘、网络三者相比较，CPU跟随用户数量的起伏最大，甚至到达100%，同时磁盘与网络的参数起伏较小，因此相比较而言，目前硬件系统未成为WEB SERVER的瓶颈。 数据库在此场景中数据库仅受到WEB SERVER的查询与读取的访问，因此数据库相应参数曲线显示较为的稳定，无大幅度的波动。 页面分解页面图片分解显示，此页面中包含了大量的图片元素，但这些页面元素分别响应时间最长的也仅为0.144second，与局域网内100M的带宽相比这是可以忽略的。对页面中的元素进行分析，http:/fgogtest/frontend/index.jsp是此页面元素中响应时间最长的，页面响应时间主要是被第一次缓存与接收所消耗，除客户端第一次访问页面外，浏览器对于再次登录平台访问页面的默认设置中有客户端缓存，再次访问平台页面的响应时间可以扣除第一次缓存所消耗的时间(平均为11-6=5秒)。因此从理论上来说，在过了初期的页面浏览与注册的高峰期后，正常运营期内客户端页面响应时间可以减少一半，同时支持的用户数应该增加一倍左右，也就意味着同样的在线容量所需的支持服务器数量可减少一半左右。2.2.2 WebLogic8.1:用例脚本：浏览首页janescriptsWebLogic包含图片URLFrontPage运行场景(scenario)：start at same time with 20 different IPs，FrontPage监控参数：Windows Resources(Memory , CPU , Network Interface),Oracle()结果分析：VUsersTRT20-5050-100100-5005SecondPassed:1,809,Failed:0Average Response Time:2.069sMaximum Running Vusers:20Duration: 03:14(mm:ss)Passed:30,354,Failed:22Average Response Time:5.602sMaximum Running Vusers:50Duration: 00:57(mm:ss)Passed:2,143,Failed:9Average Response Time:7.965sMaximum Running Vusers:100Duration: 04:11(mm:ss)10SecondPassed:3,748,Failed:0Average Response Time:2.118sMaximum Running Vusers:20Duration: 06:47(mm:ss)Passed:3,977,Failed:1Average Response Time:5.462sMaximum Running Vusers:50Duration: 07:30(mm:ss)Passed: 3,396,Failed:4Average Response Time: 9.416sMaximum Running Vusers:100Duration: 06:36(mm:ss)根据此6组数据比较分析的结果，采用同JBoss相同的测试环境(同时运行虚拟用户数50-100，页面响应时间限定在10秒以内的)，进行分析。 Summary Report同时运行虚拟用户50个，最小响应时间为1s，最大响应时间为12.234s，平均响应时间为5.462s，90%响应时间在6.12s左右，通过3，977个，失败1个。 Windows Resources.1 Memory:根据这两张图表的显示，WEB SERVER运行时内存消耗较为平稳，在同时运行50个用户时，有效内存一直很平稳，在整个测试过程中有效内存一直维持在228229Mbytes之间，与WEB SERVER的512Mbytes相比，平均值所占比例为44%左右，可见内存还有很大的空间，页面错误发生较少平均要达到23.17/sec，其中页面硬错误更少，平均只有0.076/sec,主要还是页面软错误，因此不会造成WEB页面延迟的。.2 CPU通过图表很明显地看出系统CPU资源随着同时运行用户数的大小进行着，由于目前采用的是单CPU的普通PC机，运行脚本时，CPU的处理量大多在95%100%，已经是满负荷了；进程队列数也较高，平均6.681个，最大的达到12个，这和单CPU有很大的关系，如果采用多CPU的服务器，状况就可能好转；页面切换指标显示在23978832之间，平均值达到6553，说明CPU用于切换线程资源消耗过多，这也说明了CPU成为目前系统的瓶颈。.3 网络带宽网络带宽没有随着用户数的增加而起波动，因此判定带宽还未对WEB服务器造成影响。.4 磁盘从CPU、磁盘、网络三者相比较，CPU跟随用户数量的起伏最大，很多时候甚至到达了100%，相反的磁盘与网络的参数起伏较小，因此相比较而言，CPU是目前系统的瓶颈。 数据库在此场景中数据库仅受到WEB SERVER的查询访问，因此数据库监控参数中的所有参数都显示较为平稳。 页面分解页面图片分解显示，一个页面中包含了大量的图片元素，但由于WebLogic的缓冲池优化，不会影响在页面下载过程中页面响应速度，而且在WebLogic上运行的这些页面元素的下载速度较为平均，显示出WEB SERVER相当稳定。对http:/fgogtest/frontend/index.jsp页面中的元素进行分析，页面响应时间主要是被第一次缓存与接收所消耗，除客户端第一次访问页面外，浏览器对于再次登录平台访问页面的默认设置中有客户端缓存，再次访问平台页面的响应时间可以扣除第一次缓存所消耗的时间。因此从理论上来说，在过了初期的页面浏览与注册的高峰期后，正常运营期内客户端页面响应时间可以减少大部分，同时支持的用户数应该可以成倍增加，也就意味着同样的在线容量所需的支持服务器数量可减少较多的数量。2.3 限定页面响应时间的网页浏览(无图片)通常用户玩家浏览网页所能忍受的响应时间5秒，极限能忍受的响应时间为10秒，超过10秒用户玩家将不会有耐心等下去，因此在此测试场景下，进行测试JBoss和WebLogic在限定响应时间内能支持浏览页面的用户数。2.3.1 JBoss3.2.1:用例脚本：浏览首页janescriptsJBOSS不包含图片URLFrontPage运行场景(scenario)：start at same time with 20 different IPs，FrontPage监控参数：Windows Resources(Memory , CPU , Network Interface)，Oracle()结果分析：VUsersTRT20-5050-100100-5005SecondPassed:660,Failed:0Average Response Time:3.179sMaximum Running Vusers:20Duration: 02:03(mm:ss)Passed:700,Failed:0Average Response Time:7.78sMaximum Running Vusers:50Duration: 02:05(mm:ss)Passed:1,200,Failed:20Average Response Time:13.59sMaximum Running Vusers:100Duration: 04:07(mm:ss)10SecondPassed:864,Failed:0Average Response Time:3.024sMaximum Running Vusers:20Duration: 02:22(mm:ss)Passed:1,067,Failed:0Average Response Time:7.684sMaximum Running Vusers:50Duration: 03:07(mm:ss)Passed: 1,271,Failed: 15Average Response Time: 15.042sMaximum Running Vusers:100Duration: 04:40(mm:ss)比较6组测试结果，以50-100VUsers，10Second这个测试结果与包含图片的页面进行对比。2