记一次性能测试中,因为自己设置问题,导致测试结果偏差

前言

这个性能测试真的感觉做了好久,一直都没有一个好的结果。

为什么要记录,因为想让自己以后不再犯类似错误!

要知道的几个知识点

你看完,肯定会感谢我的,建议收藏!

关于系统支持并发数计算:

1、使用系统用户数量*(5%~20%):

比如用户数为200人,平均取最大用户数为80用户左右,参考维基百科,可以自行查找

2、按照经典公式计算:

平均每天大约200人使用系统8小时,从登录到退出平均时间为4小时,那么

平均并发用户数为:C = 2004/8 = 100 并发用户数峰值为:C' = 100 + 3根号100 =130

参考自网络,感兴趣自己去查即可。

关于测试策略调整:

  • 连接及相应超时设置为3分钟
  • submitsave取样器之间间隔30秒
  • 取消设置KeepAlive

测试过程

因为测试结果一直很不理想,导致整体进度很慢,多方尝试,现把尝试方案及测试过程记录如下,以便他人参考和自己学习记录,尝试方案如下:

1、客户端设置keep-alive,默认连接、响应超时,单服务

得出结论:

经常出现数据库死锁、service not started,页面无法登陆

2、客户端设置keep-alive,默认连接、响应超时设置3分钟,单服务

经常出现数据库死锁、service not started,页面无法登陆

3、客户端取消设置keep-alive,默认连接、响应超时设置3分钟,submit与save取样器间隔1分钟,3服务

0报错,吞吐量6.1/sec,成功率100%。

4、客户端取消设置keep-alive,默认连接、响应超时设置3分钟,submit与save取样器间隔1分钟,单服务

0报错,吞吐量5.5/sec,成功率100%。

整个过程很曲折,好在遇到比较有耐心和超强的技术解决问题,也让我在这次测试中学习很多。

总结:

关于Keep-Alive设置对结果影响:

  1. 设置Keep-Alive可以避免连接建立和释放的开销,但Tcp连接容易导致系统资源无效占用,浪费系统资源。
  2. 去掉 KeepAlive可以模拟多用户访问时每次请求是从不同源端新建请求连接,能更有效模拟真实测试压力,适用于真实用户直接访问的服务接口和页面压测。
  3. 在HTTP 1.1版本后,默认开启Keep-Alive模式,可以加入 Connection: close才关闭连接,当然也可以设置Keep-Alive模式的属性,例如 Keep-Alive: timeout=5, max=100,表示这个TCP通道可以保持5秒,max=100,表示这个长连接最多接收100次请求就断开。(来自网络参考)
相关推荐
一孤程10 小时前
游戏测试专题第七篇:游戏自动化测试实战
游戏·测试
2302_8057710711 小时前
Day13Jmeter数据驱动
功能测试·单元测试·测试用例·需求分析·测试
ClouGence16 小时前
Chrome Recorder 能用于长期回归测试吗?
前端·chrome·测试
一孤程16 小时前
游戏测试专题第八篇:游戏安全测试与反外挂
游戏·测试
ClouGence18 小时前
开发提效:CueCast MCP 构建自动化测试 Agent 工作流
agent·测试·mcp
2302_805771071 天前
Day18在接口自动化测试中引入pytest用例管理框架
功能测试·单元测试·测试用例·需求分析·测试
一孤程2 天前
游戏测试专题第五篇:游戏兼容性测试与多端适配
游戏·测试
数据工匠老o3 天前
sysbench/TPC-C/自定义脚本:数据库压测工具对比与实战流程
数据库·测试
CAE虚拟与现实3 天前
什么是浏览器冒烟测试
单元测试·测试·冒烟测试·回归测试