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

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

by:授客

场景假设：

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

性能误区：

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

详细解答：

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

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

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

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

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

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

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

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

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

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

最后：

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