首先你应该测出 1000 个线程所产生的 qps,纠正一下,我前面描述有误,rps 应该为 qps,也就是测试出 1000 个线程每秒能发送多少个请求,假如你的 CPU 特别垃圾,1000 个线程只能产生 100 个 qps,那你的 CPU 负荷太高,线程可能处于任何状态。假如 1000 个线程产生的 qps 远远大于 100,那说明 CPU 负载有余,那性能瓶颈在服务器,线程大多在等待服务器响应
Tps 是服务器每秒处理的事务数量,跟多少个线程没有任何关系。多线程只为了产生更大的 rps,而 tps 不可能大于 rps。多线程并发在单核 cpu 上其实是交替执行的,只是切换时间很短,以纳秒计,所以看作是同时运行,这称为并发。还有一个相似的概念叫并行,必须不同的线程运行在不同的 CPU 核心上
我是把协议解出来,修改再发送。服务器返回的重要参数先做记录,需要发送的时候替换录制的参数
不知道你们开发能力怎么样,我倒是有个工具可以用来压测 websocket 的游戏,是需要用 lua 脚本来开发的,需要自己解析 websocket 封包,不过有现成的库,还要处理登录,报名参赛,学会使用还是有花些功夫的
自动化这个词太宽泛了,你得想好你用自动化做什么测试,仅仅是功能测试的话多开几个浏览器就可以了,无需大费周章。如果想模拟大批量用户那需要使用服务器压力测试工具,首先要明确项目使用什么协议,http(s) 还是 ws(s),长连接还是短连接。然后选择合适的工具,工具选好了,还要根据项目处理登录逻辑,报名以及比赛得逻辑。
干开发和运维的活有利于,有利于从测试的角度,优化流程,整合资源。眼界离不开测试环节,做得东西也就是想着怎么用代码替代点点点,眼界放宽了,能做的东西更多
直接通过流量录制回放,模拟 5w 个人不就行了,数量级又不大,简单粗暴一点
http 与 https 的区别就是 https 多了一层 TLS 加密,默认端口从 80 改为 443,没什么好神秘的。不过可以补充一下,服务器如果使用 openssl1.1 版本的话,在 ssl 握手阶段可能导致程序崩溃,这个版本存在 bug
理论是好的,实践成本太高
没有经历 1、3 阶段,直接 2、4,正在向 5 努力。低门槛并不容易,即使我把框架接口封装得再简单,实际使用过程中还是需要这种知识来解决各种难题,所以目前我得框架只有我一个人会用
写得很好,但是抓包没必要再解析成 json,用例一边执行一边解包就可以了