有2个问题和大家一起讨论，关于点击率和响应时间
1。第一个测试图我选择的是目标模式测试点击率，最大用户1000。上图为何点击率一开始很高，后来却又降低了呢？2。第二个测试图选的是手动模式，就是用户数到了后运行3分钟。为何在controler的响应时间里面，数据显示最大值为6.305，而图上的最大值不超过4秒呢？另外那个last是个什么数据？
[ 本帖最后由 hxgnol 于 2007-8-20 10:06 编辑 ]
回复 #1 hxgnol 的帖子
对于第一个问题：随着用户数的增加，HIT PER SECOND开始逐渐减少， 说明系统已经开始有失败的VUSER 和事务出现；对于第二个问题：6.305的这个最高点没有在图像上显示出来，LR的图像每隔几秒钟刷新一次，在刷新并且要更新图形数值的那一刻，正好错过了这个最高点的统计。
LAST---是最后60内的平均值； 原帖由 hxgnol 于 2007-8-20 09:59 发表 http://bbs.51testing.com/images/common/back.gif
1。第一个测试图我选择的是目标模式测试点击率，最大用户1000。上图为何点击率一开始很高，后来却又降低了呢？
第一个我也不知道,等高人给你解答
2。第二个测试图选的是手动模式，就是用户数到了后运行3分钟。为何在controler的响应时间里面，数 ...
第二个我也遇到了,可能跟你设置的粒度有关 顶一下~~
受教了~~ 谢谢。 后面那个问题已经解决了，但是第一个问题还是有些疑问。
1。如图，整个场景运行完后，失败的事务只有48个，这么少的数量会导致点击率在1000个用户的时候还这么少吗？1000个用户时为什么点击率反而会下降？
2。Throught的最大值为219600bytes。但是百兆网卡就算利用率为80%，1.25*80%=1MB＝1048576也比这高了一个数量级，只利用了21％，为什么这么低？
[ 本帖最后由 hxgnol 于 2007-8-20 20:37 编辑 ]
回复 #5 hxgnol 的帖子
你能把HIT PER SECOND和Throught的图形也贴出来吗？ 一会儿再来看看关于吞吐量的问题回复 #6 spartan 的帖子
点击率已经在＃1的图片里贴出来了，吞吐量和他几乎是一条曲线 有高手回答下么？学习学习 第一个问题跟缓存有关,最初用户运行时,客户端向后台发出请求,然后每个页面所包含的对象被加载,这些对象加载也计算在点击量中的,而每个页面的对象被加载过以后,就会被保存在缓存中,当后面的用户再打开同样的页面时,只需要向后台发出一次请求,相关对象的加载直接从缓存中来,这样就不计算在点击量中了,所以就看到最初点击率很高,后面下降,直到结束那条曲线都很平缓,没有大波动 你说的是内容已经保存到服务器端的缓存还是客户端的缓存，点击的结果就是一张图片，如果是保存到客户端，那直接从客户端取点击率应该为0。如果是在服务器端，不算点击率，也应该为0。可为什么结果并不为0？如果说是这个原因，那在数据进入缓存了以后，就成了测试缓存的能力了，那我就无法测试这个软件的负载能力到底如何了，如何去掉缓存的影响呢？
大家一般测试的时候是有缓存还是没有缓存呢？
[ 本帖最后由 hxgnol 于 2007-8-21 19:17 编辑 ] 关于点击率的下降。
因为在客户端发request的时候，是不会管服务器的状态的。
下面打个比方，具体数据，不可做任何参考，只是我临时编的。
比如：服务器可以同时每秒处理100次点击，这时，需要调用服务器的一些资源来处理，像：JDBC连接、内存、开socket等等，其他的用户呢？应该都在排队状态，而服务器处理完了前面的用户后，需要一些时间来释放这些被占用的资源，假设为1秒，如果LR采样的时长为2秒，那么服务器处理的用户应该为50次点击／每秒，按这种理想状态，点击率的图应该是比较平稳的。
但是，系统受的压力会随着点击的增加而增加，系统性能也就慢慢的下降，例如释放资源的速度开始变慢、换页开始频繁，那么，后面的点击造成的请求，很有可能需要等待的时间随机变长。但是采样的频率是不变的，所以后面的采样值应该慢慢的变小。
也就是像图中所显示的那样。
而出现超时的现象也很好解释了，无非是有些请求，等待的时间太长了。
[ 本帖最后由 Zee 于 2007-8-21 20:56 编辑 ] 顶，又可以学点东西了。 你的意思是不是因为服务器开始出现拥堵，导致请求连接开始排队，结果单位时间内连接数下降，那是否可以这样看：点击率能够保存一条水平线是最好，一旦出现下降就表示服务器已成为瓶颈。
另外，每次请求连接都要先开JDBC连接、内存、开socket，然后释放资源，为什么呢，比如：数据库连接池就是可以重复利用的，其它的资源能够重复利用吗？ 并不是说刚开始的时候服务器就不会出现拥塞，这个要看服务器的处理能力。
这也是曲线图下降的一种可能性，这里我只是说了一种可能性。
点击率在长时间的持续测试时，保持一条水平线最好。
并不是点击率的曲线一下降就说明是服务器的瓶颈。这需要综合分析来看。
有些资源是可以重复利用的，这些资源如果不出现争用，就不会是造成曲线下降的一种因素。
而有些资源是要需要释放掉的，那就会成为曲线下降的一种可能了。 原帖由 hxgnol 于 2007-8-21 19:09 发表 http://bbs.51testing.com/images/common/back.gif
你说的是内容已经保存到服务器端的缓存还是客户端的缓存，点击的结果就是一张图片，如果是保存到客户端，那直接从客户端取点击率应该为0。如果是在服务器端，不算点击率，也应该为0。可为什么结果并不为0？
如 ...
感觉你对点击率还是没有弄得特明白,点击率是按照客户端向后台发起了多少次请求来计算的,例如:在访问一次页面中,假设该页里面包含5个图片,那么,根据HTTP通讯的原理,用户只用点击鼠标一次就可以访问该页面,而loadrunner视该次访问的点击量为1+5=6次,我说的被缓存的内容就是指那5个图片,后面再访问该页面时,还是要向服务器发起1次请求的,点击量就变为1了,不会变成0。缓存也是指客户端，而且正常情况下程序都会用到缓存，测试时缓存的情况也需要监控的。想知道服务器有没有拥堵，看看服务器CPU使用率是多少，排队队列是多少
回复 #2 spartan 的帖子
第一个问题可能与你加载用户的时间有关.不妨把加载时间增长一下.第二个问题和你的取值粒度有关, 原帖由 apple528008 于 2007-8-22 11:00 发表 http://bbs.51testing.com/images/common/back.gif
感觉你对点击率还是没有弄得特明白,点击率是按照客户端向后台发起了多少次请求来计算的,例如:在访问一次页面中,假设该页里面包含5个图片,那么,根据HTTP通讯的原理,用户只用点击鼠标一次就可以访问该页面,而lo ...
在一般的页面测试的时候，缓存对点击率的影响确实就如apple528008说的，可能造成后面的点击率下降，但是我现在的测试脚本里面就只有一个测试连接，形如：http://..../*.jpg ，只是得到一个图片而已。那么，在这张图片已存入客户端，可以从缓存中得到的情况下，我觉得每次还是需要一个点击过去并不受缓存影响，是否可以这样理解？
个人感觉，版主说的可以解释吞吐量的下降，因为后期服务器负担加重，因此事务需要排队，这从＃1的图里也可以看到，事务响应时间随着用户的增加在递增，所以及时响应的少了，吞吐量开始下降。
可是对于点击率的下降，我觉的是LR会根据服务器的负载情况来控制客户端的点击次数 ，这在人使用的时候不可能，但是在LR这个程序里是有可能的。因为，再多的点击过去，如果是在排队那是毫无意义的，所以为了测出服务器真正的点击率，LR会根据当前流量控制客户端发起的点击，它的目标是达到一个平衡，这个平衡值就是服务器真实的可接受的点击率。至于为何图上的曲线一撅不起呢，也简单，因为当前排队的太多了，如果时间测试的久一点，应该会达到一个平衡值。
回复 #18 hxgnol 的帖子
看到了这个解释，解决了这个问题。感谢大家的参与，为我提供了解决的思路。因为并发用户数 ≠ 每秒请求数，这是两个容易让初学者混淆的概念。简单说，当你在性能测试工具或者脚本中设置了100并发用户数后，并不能期望着一定会有每秒100个请求发给服务器。事实上，对于一个虚拟用户来说，每秒发出多少请求只跟服务器返回响应的速度有关。如果虚拟用户在0.5秒内就收到了响应，那么它会立即发出第二个请求；而如果要一直等待3秒才能得到响应，它将会一直等到收到响应后才发出第二个请求。也就是说，并发用户数的设置只是保证服务器在任一时刻都有100个请求需要处理，而并不一定是保证每秒中发送100个请求给服务器。所以，只有当响应时间恰好是1秒时，并发用户数才会等于每秒请求数；否则，每秒请求数可能大于并发用户数或小于并发用户数。
[ 本帖最后由 hxgnol 于 2007-8-23 20:44 编辑 ] 学习
页:
[1]
2
