loadrunner 场景设计-学习笔记之性能误区
场景设计-学习笔记之性能误区
by:授客 QQ:1033553122
场景假设:
每个事务仅包含一次请求,执行10000个并发用户数
性能误区:
每秒并发用户数=每秒向服务器提交请求数
详细解答:
每秒并发用户数,是从客户端的视角定义的,而每秒请求数,是从服务器的视角定义的。
请求,从客户端-->网络-->服务器,中间的数据传递是需要时间的,所以10000个并发用户不一定同时到达服务器端,即每秒并发用户数 != 每秒并发请求数
此外,如果服务端接收到的请求数太多,超过请求队列的长度,服务器忙不过来,那么超过的部分将驻留在服务器的线程中,这部分的请求是不会对服务器端产生真正的负载,所以,每秒并发用户数 != 每秒并发请求数。
由此可知,常见的类似“服务器支持10000个并发用户”的性能需求,是从客户端的视角定义的,本身就存在一定的不合理性。反过来,从服务器的视角来定义性能需求--“服务器每秒能处理10000个并发请求”,似乎就比较合理了,现在的问题是:怎么样才能达到这个目的呢?
答案显而易见,增加客户端每秒并发用户数,比如15000(假定服务器能够处理这么多),这样同时到达服务器的请求数就可能达到10000个/秒。
而通常,我们期望测试结果能提供一个相对稳定的每秒请求数(RPS),要实现这个目的,得依赖持续不断的请求,所以,一般情况下,我们会对场景设置一个持续运行时间(在这个时间段内进行多次迭代),通过事务 (transaction) 的取样平均值来保证测试结果的准确性。
每个虚拟用户都在接收到来自服务响应后,下一次迭代中,重新发起新的请求,这样一来,多次的反复迭代运行可能会造成上述说的,请求数大于请求队列容量。
而我们知道,http本身是基于tcp连接的,而tcp连接又是同步协议,所以,对于每个虚拟用户来说,仅当每一个发到服务器的请求得到响应之后,才会发送下一次请求。而此时,服务器正处于忙碌的状态,一时间无法处理所有请求,这样一来,客户端接收到请求响应消息的时间间隔变长,甚至超时失败。
关键的是,当客户端请求发送出去后,LoadRunner就开始启动计时器,计算响应时间,直到它收到服务器端的响应为止。这样,得出的测试结果可能是:事务平均响应时间很长,最小响应时间与最大响应时间的差距很大,此时的平均响应时间,也就失去了它应有的意义。也就是说,由于客户端发送的请求太快而导致影响了实际的测量结果。
为了解决这个问题,我们可以在每两个事务请求之间插入一个思考时间,这将会降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间,从而提供更符合现实的响应时间。
最后:
虽然性能测试通常都是从客户端活动的角度定义的,但是它们应该以服务器为中心的视角来看待。
作者:授客
微信/QQ:1033553122
全国软件测试QQ交流群:7156436
Git地址:https://gitee.com/ishouke
友情提示:限于时间仓促,文中可能存在错误,欢迎指正、评论!
作者五行缺钱,如果觉得文章对您有帮助,请扫描下边的二维码打赏作者,金额随意,您的支持将是我继续创作的源动力,打赏后如有任何疑问,请联系我!!!
微信打赏
支付宝打赏 全国软件测试交流QQ群
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
· 【.NET】调用本地 Deepseek 模型
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库