loadrunner 场景设计-学习笔记之性能误区

时间:2022-03-14 15:45:27

场景设计-学习笔记之性能误区

by:授客 QQ1033553122

场景假设:

每个事务仅包含一次请求,执行10000个并发用户数

性能误区:

每秒并发用户数=每秒向服务器提交请求数

详细解答:

每秒并发用户数,是从客户端的视角定义的,而每秒请求数,是从服务器的视角定义的。

请求,从客户端-->网络-->服务器,中间的数据传递是需要时间的,所以10000个并发用户不一定同时到达服务器端,即每秒并发用户数 != 每秒并发请求数

此外,如果服务端接收到的请求数太多,超过请求队列的长度,服务器忙不过来,那么超过的部分将驻留在服务器的线程中,这部分的请求是不会对服务器端产生真正的负载,所以,每秒并发用户数 != 每秒并发请求数。

由此可知,常见的类似“服务器支持10000个并发用户”的性能需求,是从客户端的视角定义的,本身就存在一定的不合理性。反过来,从服务器的视角来定义性能需求--“服务器每秒能处理10000个并发请求”,似乎就比较合理了,现在的问题是:怎么样才能达到这个目的呢?

答案显而易见,增加客户端每秒并发用户数,比如15000(假定服务器能够处理这么多),这样同时到达服务器的请求数就可能达到10000个/秒。

而通常,我们期望测试结果能提供一个相对稳定的每秒请求数(RPS),要实现这个目的,得依赖持续不断的请求,所以,一般情况下,我们会对场景设置一个持续运行时间(在这个时间段内进行多次迭代),通过事务 (transaction) 的取样平均值来保证测试结果的准确性。

每个虚拟用户都在接收到来自服务响应后,下一次迭代中,重新发起新的请求,这样一来,多次的反复迭代运行可能会造成上述说的,请求数大于请求队列容量。

而我们知道,http本身是基于tcp连接的,而tcp连接又是同步协议,所以,对于每个虚拟用户来说,仅当每一个发到服务器的请求得到响应之后,才会发送下一次请求。而此时,服务器正处于忙碌的状态,一时间无法处理所有请求,这样一来,客户端接收到请求响应消息的时间间隔变长,甚至超时失败。

关键的是,当客户端请求发送出去后,LoadRunner就开始启动计时器,计算响应时间,直到它收到服务器端的响应为止。这样,得出的测试结果可能是:事务平均响应时间很长,最小响应时间与最大响应时间的差距很大,此时的平均响应时间,也就失去了它应有的意义。也就是说,由于客户端发送的请求太快而导致影响了实际的测量结果。

为了解决这个问题,我们可以在每两个事务请求之间插入一个思考时间,这将会降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间,从而提供更符合现实的响应时间。

最后:

虽然性能测试通常都是从客户端活动的角度定义的,但是它们应该以服务器为中心的视角来看待。