51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 10248|回复: 25
打印 上一主题 下一主题

[讨论] 有2个问题和大家一起讨论,关于点击率和响应时间

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-8-20 09:59:51 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
1。第一个测试图我选择的是目标模式测试点击率,最大用户1000。上图为何点击率一开始很高,后来却又降低了呢?
2。第二个测试图选的是手动模式,就是用户数到了后运行3分钟。为何在controler的响应时间里面,数据显示最大值为6.305,而图上的最大值不超过4秒呢?另外那个last是个什么数据?


[ 本帖最后由 hxgnol 于 2007-8-20 10:06 编辑 ]

本帖子中包含更多资源

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

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

使用道具 举报

  • TA的每日心情
    郁闷
    2017-1-11 15:48
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    2#
    发表于 2007-8-20 10:37:12 | 只看该作者

    回复 #1 hxgnol 的帖子

    对于第一个问题:随着用户数的增加,HIT PER SECOND开始逐渐减少, 说明系统已经开始有失败的VUSER 和事务出现;

    对于第二个问题:6.305的这个最高点没有在图像上显示出来,LR的图像每隔几秒钟刷新一次,在刷新并且要更新图形数值的那一刻,正好错过了这个最高点的统计。
    LAST---是最后60内的平均值;
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2007-8-20 11:04:22 | 只看该作者
    原帖由 hxgnol 于 2007-8-20 09:59 发表
    1。第一个测试图我选择的是目标模式测试点击率,最大用户1000。上图为何点击率一开始很高,后来却又降低了呢?

    第一个我也不知道,等高人给你解答
    2。第二个测试图选的是手动模式,就是用户数到了后运行3分钟。为何在controler的响应时间里面,数 ...


    第二个我也遇到了,可能跟你设置的粒度有关
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2007-8-20 13:20:08 | 只看该作者
    顶一下~~
    受教了~~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
     楼主| 发表于 2007-8-20 20:23:14 | 只看该作者
    谢谢。 后面那个问题已经解决了,但是第一个问题还是有些疑问。
         1。如图,整个场景运行完后,失败的事务只有48个,这么少的数量会导致点击率在1000个用户的时候还这么少吗?1000个用户时为什么点击率反而会下降?
          2。Throught的最大值为  219600bytes。但是百兆网卡就算利用率为80%,1.25*80%=1MB=1048576也比这高了一个数量级,只利用了21%,为什么这么低?


    [ 本帖最后由 hxgnol 于 2007-8-20 20:37 编辑 ]

    本帖子中包含更多资源

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

    x
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2017-1-11 15:48
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    6#
    发表于 2007-8-21 14:05:12 | 只看该作者

    回复 #5 hxgnol 的帖子

    你能把HIT PER SECOND和Throught的图形也贴出来吗?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2007-8-21 14:41:06 | 只看该作者
    一会儿再来看看关于吞吐量的问题
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
     楼主| 发表于 2007-8-21 14:44:40 | 只看该作者

    回复 #6 spartan 的帖子

    点击率已经在#1的图片里贴出来了,吞吐量和他几乎是一条曲线
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2007-8-21 16:41:33 | 只看该作者
    有高手回答下么?学习学习
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2007-8-21 16:51:02 | 只看该作者
    第一个问题跟缓存有关,最初用户运行时,客户端向后台发出请求,然后每个页面所包含的对象被加载,这些对象加载也计算在点击量中的,而每个页面的对象被加载过以后,就会被保存在缓存中,当后面的用户再打开同样的页面时,只需要向后台发出一次请求,相关对象的加载直接从缓存中来,这样就不计算在点击量中了,所以就看到最初点击率很高,后面下降,直到结束那条曲线都很平缓,没有大波动
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
     楼主| 发表于 2007-8-21 19:09:37 | 只看该作者
    你说的是内容已经保存到服务器端的缓存还是客户端的缓存,点击的结果就是一张图片,如果是保存到客户端,那直接从客户端取点击率应该为0。如果是在服务器端,不算点击率,也应该为0。可为什么结果并不为0?
    如果说是这个原因,那在数据进入缓存了以后,就成了测试缓存的能力了,那我就无法测试这个软件的负载能力到底如何了,如何去掉缓存的影响呢?
    大家一般测试的时候是有缓存还是没有缓存呢?


    [ 本帖最后由 hxgnol 于 2007-8-21 19:17 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2007-8-21 20:39:20 | 只看该作者
    关于点击率的下降。
    因为在客户端发request的时候,是不会管服务器的状态的。

    下面打个比方,具体数据,不可做任何参考,只是我临时编的。
    比如:服务器可以同时每秒处理100次点击,这时,需要调用服务器的一些资源来处理,像:JDBC连接、内存、开socket等等,其他的用户呢?应该都在排队状态,而服务器处理完了前面的用户后,需要一些时间来释放这些被占用的资源,假设为1秒,如果LR采样的时长为2秒,那么服务器处理的用户应该为50次点击/每秒,按这种理想状态,点击率的图应该是比较平稳的。
    但是,系统受的压力会随着点击的增加而增加,系统性能也就慢慢的下降,例如释放资源的速度开始变慢、换页开始频繁,那么,后面的点击造成的请求,很有可能需要等待的时间随机变长。但是采样的频率是不变的,所以后面的采样值应该慢慢的变小。
    也就是像图中所显示的那样。

    而出现超时的现象也很好解释了,无非是有些请求,等待的时间太长了。

    [ 本帖最后由 Zee 于 2007-8-21 20:56 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2007-8-21 20:51:05 | 只看该作者
    顶,又可以学点东西了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
     楼主| 发表于 2007-8-21 21:13:36 | 只看该作者
    你的意思是不是因为服务器开始出现拥堵,导致请求连接开始排队,结果单位时间内连接数下降,那是否可以这样看:点击率能够保存一条水平线是最好,一旦出现下降就表示服务器已成为瓶颈。

    另外,每次请求连接都要先开JDBC连接、内存、开socket,然后释放资源,为什么呢,比如:数据库连接池就是可以重复利用的,其它的资源能够重复利用吗?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2007-8-21 21:46:18 | 只看该作者
    并不是说刚开始的时候服务器就不会出现拥塞,这个要看服务器的处理能力。
    这也是曲线图下降的一种可能性,这里我只是说了一种可能性。
    点击率在长时间的持续测试时,保持一条水平线最好。
    并不是点击率的曲线一下降就说明是服务器的瓶颈。这需要综合分析来看。

    有些资源是可以重复利用的,这些资源如果不出现争用,就不会是造成曲线下降的一种因素。
    而有些资源是要需要释放掉的,那就会成为曲线下降的一种可能了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2007-8-22 11:00:26 | 只看该作者
    原帖由 hxgnol 于 2007-8-21 19:09 发表
    你说的是内容已经保存到服务器端的缓存还是客户端的缓存,点击的结果就是一张图片,如果是保存到客户端,那直接从客户端取点击率应该为0。如果是在服务器端,不算点击率,也应该为0。可为什么结果并不为0?
    如 ...

    感觉你对点击率还是没有弄得特明白,点击率是按照客户端向后台发起了多少次请求来计算的,例如:在访问一次页面中,假设该页里面包含5个图片,那么,根据HTTP通讯的原理,用户只用点击鼠标一次就可以访问该页面,而loadrunner视该次访问的点击量为1+5=6次,我说的被缓存的内容就是指那5个图片,后面再访问该页面时,还是要向服务器发起1次请求的,点击量就变为1了,不会变成0。缓存也是指客户端,而且正常情况下程序都会用到缓存,测试时缓存的情况也需要监控的。想知道服务器有没有拥堵,看看服务器CPU使用率是多少,排队队列是多少
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2007-8-22 15:15:30 | 只看该作者

    回复 #2 spartan 的帖子

    第一个问题可能与你加载用户的时间有关.不妨把加载时间增长一下.
    第二个问题和你的取值粒度有关,
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
     楼主| 发表于 2007-8-22 19:13:58 | 只看该作者
    原帖由 apple528008 于 2007-8-22 11:00 发表

    感觉你对点击率还是没有弄得特明白,点击率是按照客户端向后台发起了多少次请求来计算的,例如:在访问一次页面中,假设该页里面包含5个图片,那么,根据HTTP通讯的原理,用户只用点击鼠标一次就可以访问该页面,而lo ...



    在一般的页面测试的时候,缓存对点击率的影响确实就如apple528008说的,可能造成后面的点击率下降,但是我现在的测试脚本里面就只有一个测试连接,形如:http://..../*.jpg ,只是得到一个图片而已。那么,在这张图片已存入客户端,可以从缓存中得到的情况下,我觉得每次还是需要一个点击过去并不受缓存影响,是否可以这样理解?

    个人感觉,版主说的可以解释吞吐量的下降,因为后期服务器负担加重,因此事务需要排队,这从#1的图里也可以看到,事务响应时间随着用户的增加在递增,所以及时响应的少了,吞吐量开始下降。
    可是对于点击率的下降,我觉的是LR会根据服务器的负载情况来控制客户端的点击次数 ,这在人使用的时候不可能,但是在LR这个程序里是有可能的。因为,再多的点击过去,如果是在排队那是毫无意义的,所以为了测出服务器真正的点击率,LR会根据当前流量控制客户端发起的点击,它的目标是达到一个平衡,这个平衡值就是服务器真实的可接受的点击率。至于为何图上的曲线一撅不起呢,也简单,因为当前排队的太多了,如果时间测试的久一点,应该会达到一个平衡值。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
     楼主| 发表于 2007-8-23 20:43:09 | 只看该作者

    回复 #18 hxgnol 的帖子

    看到了这个解释,解决了这个问题。感谢大家的参与,为我提供了解决的思路。
            因为并发用户数 ≠ 每秒请求数,这是两个容易让初学者混淆的概念。简单说,当你在性能测试工具或者脚本中设置了100并发用户数后,并不能期望着一定会有每秒100个请求发给服务器。事实上,对于一个虚拟用户来说,每秒发出多少请求只跟服务器返回响应的速度有关。如果虚拟用户在0.5秒内就收到了响应,那么它会立即发出第二个请求;而如果要一直等待3秒才能得到响应,它将会一直等到收到响应后才发出第二个请求。也就是说,并发用户数的设置只是保证服务器在任一时刻都有100个请求需要处理,而并不一定是保证每秒中发送100个请求给服务器。所以,只有当响应时间恰好是1秒时,并发用户数才会等于每秒请求数;否则,每秒请求数可能大于并发用户数或小于并发用户数。


    [ 本帖最后由 hxgnol 于 2007-8-23 20:44 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2007-8-24 10:15:36 | 只看该作者
    学习
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-8 10:59 , Processed in 0.080937 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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