记录一下自己最近的工作状况---老…

打折网性能 测 试

场景一：总共2000个用户分配的场景如下：

 

Web服务器的使用资源如下：

 

DB服务器的使用资源如下：

 

场景一总结：

混合场景总共2000个用户，除去goodslist页面457个用户，有1534个用户在使用该系统。大约在虚拟用户数增加到900个时候Web服务器上出现已排队的请求数量Requests Queued开始不能被处理掉。在测试的过程中Web服务器的CPU使用平均为38.344%，DB数据库服务器的CPU使用平均为8.651%。

 

场景二：在场景一中去除掉商品搜索（Searcdgoods_new）这个脚本，目的是用来确定是否是商品搜索造成Web服务器上Requests Queued排队的原因。

Web服务器的使用资源如下：

 

DB服务器的使用资源如下：

 

场景二总结：

该场景总共1494个虚拟用户在使用该系统，在整个测试过程中Web服务器上没有出现过Requests Queued的累积（偶尔会出现1-2个队列但是服务器能够立即处理掉）。在测试的过程中Web服务器的CPU使用平均为33.837%，DB数据库服务器的CPU使用平均为7.126%。

 

 

场景三：在场景三中去除掉商品最终页（goodsdetail20110529）这个脚本，另外再恢复商品所搜页（Searcdgoods_new）脚本，目的是用来确定是否是商品最终页造成Web服务器上Requests Queued排队的原因。

Web服务器的使用资源如下：

 

DB服务器的使用资源如下：

 

场景三总结：

该场景总共1112个虚拟用户在使用该系统，在整个测试过程中Web服务器上没有出现过Requests Queued的累积，在测试的过程中Web服务器的CPU使用平均为9.222%，DB数据库服务器的CPU使用平均为13.640%。

 

场景四：把商品最终页（goodsdetail20110529）和商品所搜页（Searcdgoods_new）进行组合，商品最终页面设置500个用户访问，商品所搜页设置100个用户访问。目的是用来确定这二个页面是否相互存在影响。

Web服务器的使用资源如下：

 

DB服务器的使用资源如下：

 

场景四总结：

该场景总共有600个用户访问系统，当用户数达到180个的时候（商品最终页150个用户，商品搜索页30个用户）的时候Loadruner中开始报了一个http500错误，当用户数达到220个时候（商品最终页183个用户，商品搜索页37个用户）的时候loadrunner开始报第一个404错误http://test10.dazhe.cn/error/error.aspx?info=empty。

在600个虚拟用户同时上线后Web服务器的CPU使用平均在35.476%左右，DB数据库服务器的CPU使用在9.099%左右，并且Web服务器上Requests Queued上的队列排队数在300个左右。当虚拟用户数在140-160的时候Web服务器上的Requests Queued开始排队累积，证明这二个脚本组合起来性能效果较差。

 

场景五：把商品最终页面做为单场景单交易单独测试，目的是确定该页面的性能如何，是否要考虑从该页面进行优化。

使用用户数：1200

Web服务器的使用资源如下：

DB服务器的使用资源如下：

 

WEB处理队列中的线程数Processor Queue Lenth如下：

 

场景五总结：

1200个用户同时在线访问商品最终页面的时候，Web服务器有队列，但是能够立即处理掉。当1200个用户同时在线的时候Web服务器的CPU平均使用百分率为60.384%，DB服务器的CPU平均使用百分率为8.274%。

该页面的的Web服务器的队列能够处理掉，但是Processor Queue Lenth的平均值一般情况下大于2，并且CPU的平均使用百分率较高维持在60%左右，证明该页面存在性能上的瓶颈（主要是对CPU的资源消耗较大）。如果用户访问量增大的话该页面需要进行优化。

 

场景六：把商品搜索页面做为单场景单交易单独测试，目的是确定该页面的性能如何，是否要考虑从该页面进行优化。

使用用户数：500

 

Web服务器的使用资源如下：

 

DB服务器的使用资源如下：

 

DB处理队列中的线程数Processor Queue Lenth如下：

 

场景六总结：

当500个用户同时上线之后,Web服务器的CPU使用平均为8.031%，DB数据库服务器的CPU使用达到99.035%，另外Web服务器上没有Requests Queued排队现象，DB数据库服务器上Requests Queued排队数量为40-60之间。DB数据库处理队列中的线程数Processor Queue Lenth为8.778左右且这个值大于2，并且DB数据库的CPU使用明显过高，所以证明数据库服务器的的CPU此时出现了瓶颈，但是这么高的CPU主要消耗在数据库服务器的w3wp.exe上面。

 

场景七：把商品列表页作为一个单独的场景测试。

 

场景七测试总结：当虚拟用户数目到达80个左右的时候，开始报500代码错误，说明该页面在多用户访问量的情况下会出现程序上的缺陷Bug。另外当虚拟用户数目达到320个左右的时候数据库服务器上的CPU平均值超过70%以上，CPU主要消耗在数据库服务器的w3wp.exe上面。

 

测试总结：

（1）商品最终页（goodsdetail）的性能经过上次优化之后依然性能较为差一些（主要是表现在1200个用户访问商品最终页面的时候，Web服务器的CPU平均值维持在60%左右）这个值应该还是稍微高了一些，从其他页面的测试结果来分析，如果商品最终页面能优化到1200个用户访问商品最终页面的CPU平均值维持在30-40%之间的应该能解决Web服务器上对列排队的一些问题。

 

（2）商品搜索页（serarch goods）对数据库的CPU使用明显过高，所以证明数据库服务器的的CPU此时出现了瓶颈，但是这么高的CPU主要消耗在数据库服务器的w3wp.exe上面。DB数据库服务器上Requests Queued有排队。当500个用户同时在线的时候DB数据库服务器上Requests Queued排队数量一般维持在40-60之间。

 

（3）商品最终页和商品搜索页面组合在一起的性能效果较差，这二个场景组合在一起测试，场景中会报一些404错误http://test10.dazhe.cn/error/error.aspx?info=empty，并且Web服务器上的队列排队现象严重。当虚拟用户数在600个时候（商品最终页500个用户，商品搜索页100个用户）Web服务器上Requests Queued排队数目在300个左右，证明这二个页面组合在一起性能较差。但是目前从测试的角度来说并不能确定这二个页面是否存在相互影响。

 

（5）商品列表页goodsliest在并发用户访问量的情况下会出现500错误，这个页面的程序在并发用户访问量的情况下程序中可能有缺陷Bug。另外该页面在虚拟用户数目达到320个左右的时候数据库服务器上的CPU平均值超过70%以上，CPU主要消耗在数据库服务器的w3wp.exe上面。

 

（6）另外在最近在测试promotionbranddetail品牌特卖专区页过程中出现一些错误，暂时排除LR脚本的问题，但是还不能确定是否是网络因素造成的，还是程序当中的缺陷造成的。