qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

怎样才能测试WEB系统支持多少用户

1 怎样的性能测试结果才是有效的

  1.1 错误观点

  性能测试工具运行一定用户数都成功,则表示该服务器能支持这么多用户数。这是错误的。

  解答:

  A.        因为一次有效的测试结果,不只用户都运行成功,同时需要保证访问一个页面或一次交易的响应时间在合理范围。“2-5-8原则”,简单说,就是当用户访问一个页面或一次交易能够在2秒以内得到响应时,会感觉系统的响应很快;当用户在2-5秒之间得到响应时,会感觉系统的响应速度还可以;当用户在5-8秒以内得到响应时,会感觉系统的响应速度很慢,但是还可以接受;而当用户在超过8秒后仍然无法得到响应时,会感觉系统糟透了,或者认为 系统已经失去响应,而选择离开这个Web站点,或者发起第二次请求。

  B.        测试场景不一定模拟了真实业务场景,因为浏览器是并发多线程多TCP完成一个页面的,而测试工具基本都是1,2个线程;对服务器的压力是不一样的,真实环境的TCP压力是性能测试工具虚拟环境的几倍。

  2 影响WEB服务器性能指标的因素有哪些

  为什么性能测试工具,需要提供事务(页面或交易、全脚本)指标、TCP连接、吞吐量、服务器资源监控、请求数/响应数。

  1)        硬件资源:如CPU、内存、网卡吞吐量、I/O能力、SWAP交换能力

  2)        线程数:这里介绍JAVA的WEB服务器,默认每线程占用的内存为2M,而32为系统JAVA进程(如tomcat、JBoss)占得空间只有2G(一般比这个小),因此线程数有限制;64为无限制线程,但CPU要跟得上

  3)        TCP连接数:操作系统的TCP连接数理论值一般很大,操作系统对TCP连接设置有默认值(怎么配置,可以网上搜索,这里不介绍);但实际测试中TCP连接在几百,就出现测试的响应时间很长。抓包分析,原来是三次握手的SYN包服务器不及时响应,导致SYN重传(3秒后,9秒后)。

  如果SYN丢了,则会重发,但是第一次是3秒后,第2次是在9秒后,如果重发才收到的SYN_ACK,则导致TCP连接超长,从而导致业务响应时间延长。

  4)        响应时间:服务器响应时间小,用户体验才好,在大量用户并发的情况下,HTTP响应时间在用户忍受度下才是有效的,一般采用“2-5-8原则”。

  5)        软件本身代码性能算法:这个不做介绍,如差的算法、查询数据库时间长等等。

  3 测试人员经常遇到的一些常见问题及解答

  3.1        为什么使用浏览器访问页面响应很快,1-2秒就完成;而使用测试工具却需要10几秒,甚至几十秒才完成脚本

  解答:

  A.        这是由于浏览器访问页面响应是并发的,同时并发多个线程(多个Socket),而性能测试工具基本是串行发送请求的。如果一个页面有100个资源(CSS、HTML、JS、图片),需要发送100个HTTP请求,如果使用6个线程(浏览器),则每个大概请求14个HTTP;如果使用一个线程(测试工具),则需要请求100个,时间当然大很多。下图为chrome浏览器调试工具显示的并发情况:

  B.        另外浏览器具有缓存功能,如果之前访问了www.qq.com,会把一些图片缓存在浏览器临时目录,下次请求时发送的HTTP请求会带上If-Match或Etag等头域,WEB服务器判断资源没改变则会304响应,而不是回200 OK,这样减少资源的传输,所以时间就小。而有些测试工具是不携带这些头域(包括Loadrunner),因此回的响应是200 OK。所以测试人员默认真实测试时,可以考虑部分有缓存,部分没缓存。

  3.2        性能测试工具是怎么模拟WEB虚拟用户

  A.        录制

  使用浏览器进行正常业务操作,性能测试工具录制下HTTP请求信息。一般需要记录URL与头域、内容、响应码。虽然不同的性能测试工具录制方式不一样(如loadrunner采用Hook,JMeter采用代理或badbody,kylinPET采用网卡抓包与代理),但都能实现录制正常业务的HTTP请求。

  测试工具最好能录制出缓存头域,即If-Match或Etag,loadrunner好像不支持录制缓存头域。

  B.        模拟用户

  根据录制的脚本发送HTTP请求与接收响应,发送前替换参数(实现多用户不同参数值)、接收时关联参数(从接收的响应消息获取参数值,如Cookie、JSessionID)

  下面简单列举使用过的性能测试工具是如何模拟的(工具运行一个用户,然后使用wireshark抓包分析得到的结论):

          Loadrunner:根据录制脚本发送HTTP请求,如果HTTP请求包括内嵌资源(如图片、CSS、JS),会启动第二个线程执行内嵌资源,即Loadrunner支持同时两个线程两个TCP连接。

          kylinPET(国产):可通过配置设置一个线程或者多个线程并发发送HTTP请求,多个线程并发及TCP连接数跟浏览器行为一样。

          JMeter:只有一个线程,一个TCP连接

          其他工具:本人没用过,请用过的兄弟姐妹可以补充下。通过wireshark抓包分析。

 3.3        怎样才能测试出WEB服务器能支持多少真实用户,怎样的服务器调优参数才合理

  解答:

  这需要性能测试工具可以模拟出真实用户的行为,包括HTTP请求数、每用户并发线程与TCP连接数、思考时间、有无缓存。

  为什么需要模拟真实用户的线程数与TCP连接数呢,上面提到过,WEB服务器的线程数与TCP连接数往往很低,这不是提高硬件就能轻松解决的,这也是服务器调优比较复杂的配置。

  因此,只有尽最大能力模拟真实用户(浏览器或其它WEB客户端,可能不同浏览器的并发线程与TCP数都不一样)的行为的测试场景,测试结果才最真实,服务器调优才最有意义。

  4 怎样才能测试系统支持多少用户

  4.1 模拟真实用户的行为

  只有模拟用户一样的行为才可以系统支持的测试用户数有效,因此需要模拟一样的并发数、TCP连接数、甚至可以是HTTP请求的时间间隔。用户可以是浏览器、智能手机、智能机顶盒,测试工具模拟他们一样的行为才是最有效的测试。

  4.2 测试结果数据在合理范围

  4.2.1 用户统计

  成功数、失败数、每秒在线数、最大在线数,通过这些指标分析此次测试结果支持的用户数、用户最大数

  4.2.2 点击率

  每秒平均HTTP请求数、响应数。分析系统的处理能力

  4.2.3 事务

  事务成功、失败、时间,事务一般是整个脚本运行时间、或者一个页面或一个交易,通过结果分析,得出每个事物的时间是否合理,符合“2-5-8”原则,如果测试结果显示事物时间非常大,则表示系统支持不了此次测试的用户,因为用户的响应时间太大(像火车订票一样,太多用户导致响应时间长,用户无法忍受,则认为这个系统烂)。

  当然,还需要查看事务的百分比,分析90%、80%、70%、60%的事务时间是否在合理范围。

  4.2.4 TCP连接信息

  TCP连接成功数、失败数、TCP三次握手时间。因为此次测试结果可能是由于服务器系统或网络的TCP的丢包与重传才导致延时大的。如果是服务器的原因,服务器收到TCP的SYN而不处理,可以通过调试服务器的TCP配置来优化。

  怎么才知道是服务器的问题呢,这个需要性能测试工具能给出TCP连接时间(当前了解只有kylinPET可以支持),如果显示超过3秒,这时需要检查是网络还是服务器问题,可以在服务器端抓包(tcpdump或wireshark)然后分析TCP的SYN信息(个数、时间)

  4.2.5 资源占用

  服务器的CPU、内存、带宽、I/O是不是已经不足,导致系统上不去是哪个原因,根据原因进行调优或升级。

  测试时需要考虑性能测试工具的CPU占用率,如果性能测试工具占用CPU很高,此次测试可能瓶颈是在工具,而导致测试结果是无效的。

  原帖地址:http://bbs.51testing.com/thread-980437-1-1.html

版权声明:本文由会员linneiwei首发于51Testing软件测试论坛。

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。


posted on 2013-07-10 10:46 顺其自然EVO 阅读(1336) 评论(0)  编辑  收藏 所属分类: loadrunnerweb 前端性能测试


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年7月>
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜