51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 19168|回复: 39
打印 上一主题 下一主题

[原创] 怎样才能测试WEB系统支持多少用户

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2013-6-19 22:00:17 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
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很高,此次测试可能瓶颈是在工具,而导致测试结果是无效的。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x

评分

参与人数 1综合技术指数 +30 收起 理由
lsekfe + 30

查看全部评分

分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏10
回复

使用道具 举报

该用户从未签到

推荐
 楼主| 发表于 2013-6-25 20:32:51 | 只看该作者
希望能与大家在性能测试技术领域一起进步,大家有测试方面的问题或总结,可以加群讨论或共享,群号:65917724
回复 支持 0 反对 1

使用道具 举报

  • TA的每日心情
    慵懒
    2015-7-31 14:22
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    2#
    发表于 2013-6-20 10:33:59 | 只看该作者
    沙发?顶楼主!好东西!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2013-6-20 22:33:58 | 只看该作者
    lz还有没有要发表的,继续哇,
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2013-6-24 14:54:47 | 只看该作者
    不错,是个好东西。怪不得我们用loadrunner测试老是响应时间很长,跟浏览器响应时间差好多,总不知道是什么原因,原来是由于loadrunner并发数与浏览器不一样的问题。

    使用了kylinPET的模拟浏览器功能,确实响应时间小啦,不错,顶国产
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2013-6-24 15:40:06 | 只看该作者
    学习下。一直在用LoadRunner 都11。5了。还是问题多多啊。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2013-6-24 15:52:05 | 只看该作者
    好东西,谢谢分享!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2013-6-26 10:42:08 | 只看该作者
    3.1        为什么使用浏览器访问页面响应很快,1-2秒就完成;而使用测试工具却需要10几秒,甚至几十秒才完成脚本

    这个问题大部分情况都应该先排查测试端是不是有网络带宽瓶颈
    另外
    “这是由于浏览器访问页面响应是并发的,同时并发多个线程(多个Socket),而性能测试工具基本是串行发送请求的”

    串行发送请求说法并不准确,脚本是串行的 ,但是请求并不是串行的,就算web脚本基于URL,也有并发组函数避免脚本串行执行带来的请求并行的问题
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2013-6-26 10:45:27 | 只看该作者
    1.1 错误观点
    性能测试工具运行一定用户数都成功,则表示该服务器能支持这么多用户数。

    这个问题的根本错误应该是:测试工具的从来都是线程数,不是用户数,线程数和用户数实际上是两码事

    应该关注的是如何能够模拟到生产环境的一段峰值中的每秒请求/并发数
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
     楼主| 发表于 2013-6-26 21:39:48 | 只看该作者
    回复 8# mr.bee


        版主可能理解错了我的意思。
    1、 多用户并发肯定是并行的,每个测试工具都是
    2、但每个用户的请求很多工具是串行的,loadunner当前也只是每个用户最多只并行两个线程
         浏览器标准是规定并发2个,但由于现在WEB发展很快,一个页面的HTTP请求现在已经很大,所以当前浏览器默认一般是6个并发去并行请求资源,但当页面资源很多时,浏览器就会超过6个并发
        这个可以使用wireshark抓包工具、浏览器自带调试工具(按F12)、httpWatcher就可以知道

        loadrunner老版本一直是每用户两个并发(100个用户就200个并发啦),直到现在一直没改,假设一个页面有120个HTTP请求,2个并发响应时间肯定远小于6个并发,甚至18个并发

    3、所以说很多测试工具是串行的(我指的是每个虚拟用户)执行HTTP请求;loadrunner功能强大些,每个用户可以达到2个并发;然后研究过kylinPET,确实每个虚拟用户达到浏览器录制时一样的并发
         研究方法,很简单,使用wireshark抓包工具查看每个请求的时间是不是一个请求然后一个响应,还是多个请求同时的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
     楼主| 发表于 2013-6-26 22:13:20 | 只看该作者
    回复 9# mr.bee

    您的问题1、测试工具的从来都是线程数,不是用户数,线程数和用户数实际上是两码事
    回答:
            那是因为测试工具能力问题,如果可以实现模拟用户数,那测试工具能力就更强,假设模拟浏览器,如果能模拟浏览器一样的并发,请求时间间隔跟浏览器录制时一样,即可达到模拟用户的能力。
            除去浏览器的渲染不考虑,我们只考虑浏览器底层的HTTP请求,如果你能模拟浏览器底层的HTTP能力,即可以实现模拟一个真实用户对服务器的压力。
            渲染是浏览器自己的,且是客户端自己的,所以测试工具不用考虑这个。

           然后如果测试结果显示不是测试工具问题,测试工具自己CPU不高(CPU高的话,响应时间长就也包括了测试工具处理时间),吞吐量正常,那么基本可以认为浏览器模拟了。

          所以,模拟用户(浏览器或其他如智能终端)不是不可以做到,只是测试工具自身能力问题。我们目前项目使用的是kylinPET工具,他们确实做到了模拟浏览器的能力。

    您的问题2、应该关注的是如何能够模拟到生产环境的一段峰值中的每秒请求/并发数

    1、这个是正确的,但你怎么去评估呢。
        1)假设你模拟到了生产环境的每秒请求/并发数,你知道你的系统能支持多少用户吗?我是不知道,因为有很多不确定因素
            实际是实际情况实际处理,如果你测试时面向用户的(如浏览器),你的每秒请求/并发数只是一个指标而已,还有响应时间(假设你达到了每秒请求/并发数,但响应时间很大,你的测试可以说是没什么用的)
            如果你测试的是后台里一个跟你在一个局域网且连接数固定的(如有连接池,或其他远程接口调用),这种你的测试每秒请求/并发数就很重要,因为影响因素就少很多)
        2)你领导让你测试,肯定不会说让你测试能不能达到多少HTTP请求/秒;而是让你测试能不能支持多少用户。
        3)只有面向用户的测试才是让性能测试更好理解,不然很多人测试后都不知道能支持多少用户。

    2、TCP连接其实是一个很重要的指标,很多时候性能上不去就是这个原因,很多测试人员都没去关注或不知道怎么关注
        1)如tomcat这类WEB服务器,如果没有非阻塞IO或异步IO,TCP连接会跟线程绑定,而tomcat线程池一般都很小,而且线程池不一定是越大越好,要经过性能测试与时间业务给出合理的线程池
             所以如果你没摸你浏览器一样的TCP连接并发,你是很难调优的,也不知道支持多少用户。
        2)系统TCP连接资源也是有限制的,如linux的一些系统调优就涉及这个
        3)性能测试工具,如loadrunner只给出多少TCP连接成功、失败,其实在大量TCP下,TCP重传很常发生,这个会导致响应时间变长,如TCP三次握手时间,loadrunner就没给出,另一个性能工具kylinPET就给出了这个指标

    3、所以,我特别强调模拟真实用户,如浏览器(或其他如智能手机、机顶盒),是很有必要的,因为,性能测试的目的就是了解系统能支持多少用户,而不是支持多少每秒请求/并发数,从用户角度来看性能测试才好理解,很多指标就
         能简单理解。
         如,模拟了真实用户,你就知道响应时间是否合理,而不是看不懂,因为用户访问一个页面,响应应该多长时间是有个合理范围的(业界一般说2-5-8原则)

        只是当前很多测试工具难以实现模拟浏览器的能力,目前就了解kylinPET性能工具基本做到啦,当然,测试工具要能模拟真实用户要能做到线程数就是用户数(并发几个线程等于一个用户),瓶颈不要出现在测试工具,不然事务的响应时间长可能是由于测试工具,所以测试时不要让测试工具CPU占用太高,如果太高,就把并发用户分到多个执行器。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2013-6-28 09:10:23 | 只看该作者
    楼主是强人啊。这么好的文章要顶起。

    确实有道理,loadrunner指标总是看不明白,不知道合不合理,有些用户响应时间短,有些用户响应时间长,然后每秒处理数怎么换算成用户,一直搞不懂。

    楼主说得好,如果是从用户角度上考虑的话,测试数据合理不合理跟用户数关联起来就好理解;
    原来事务应该这样设置的啊,每个页面或交易设置一个事务,然后从用户角度测试,事务太高就说明用户不符合指标,学习啦

    没想到loadrunner到11.5啦还是很多不支持
    请问楼主,kylinPET性能工具免费吗,哪里可以下载呢
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
     楼主| 发表于 2013-6-30 13:26:50 | 只看该作者
    kylinPET工具可以到他们的官网下载www.kylinpet.com,使用还是挺方便的。

    大家使用性能工具,不管是loadrunner还是kylinPET,都需要注意测试工具机器的CPU、吞吐量,避免瓶颈在工具导致测试效果不好。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2013-7-2 09:10:14 | 只看该作者
    下载啦,确实不错

    居然有回放与录制比较,这个定位脚本问题就方便多啦
    还有运行后参考事务时间值,可以一目了然看出响应时间与录制的响应时间差别大不大

    好东西,顶
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2013-7-2 10:31:53 | 只看该作者
    初步了解中,好东东,顶起!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2018-10-10 09:25
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    16#
    发表于 2013-7-2 13:30:20 | 只看该作者
    不错的文章~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2013-7-3 15:47:17 | 只看该作者
    推荐,非常好的文章
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2013-7-3 15:47:29 | 只看该作者
    推荐,非常好的文章
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    昨天 09:13
  • 签到天数: 1043 天

    连续签到: 1 天

    [LV.10]测试总司令

    19#
    发表于 2013-7-3 15:58:05 | 只看该作者
    小编看到好文章激动了!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2020-7-17 08:14
  • 签到天数: 9 天

    连续签到: 1 天

    [LV.3]测试连长

    20#
    发表于 2013-7-7 21:48:04 | 只看该作者
    回复 13# linneiwei


        测试工具所在机器是否有瓶颈 有没有好的方法验证?
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-12 06:48 , Processed in 0.077964 second(s), 31 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表