这个时候你需要一个可编程的压测工具,很简单的功能用 Jmeter 反而复杂了
很感兴趣,楼主是帮忙内推吗 ?
对的,就 jmeter 而言,多做几次你就发现会有一个单机效率最高的线程数量配置区间,也就是网友总结出来的大概 1000 到 3000 个线程,具体跟 CPU 性能相关,以此为基础进行分布式扩展
通常并发是指 1 秒钟之内发出的请求数,单线程也可以并发上千上万,跟线程数量没有必然关系。因为 jmeter 用线程模拟用户,线程在 cpu 上的切换也需要消耗时间,剩下的才是实际执行逻辑运算的时间,线程越多切换时间就越多,实际执行逻辑运算的时间就越少,真正能并发多少个线程不是固定的,受线程中 IO 阻塞时间而定,而 IO 又是十分耗时且不稳定的,所以 jmeter 很难计算一个最具有效率的线程数量。压测过程实际并发数只能通过执行过程中进行统计
线程太多,大量的 CPU 时间都用在了线程切换上,实际并发数量并不等于线程数量
压测经验理论大多千篇一律,没什么好讲。做为一个有游戏服务器压测落地经验的大概说一下压测的几个作用:1。发现系统缺陷,用户多运行时间长时能发现一些很难发现又很严重的 bug;2.描述技术性能,服务于开发的一些性能指标数据,如接口响应时间;3.描述业务性能,老板最关心的指标,如最大承载用户,我就遇到过开发临时无法优化代码的情况下通过修改产品设计来达到需求。很多人把技术性能和业务性能混为一谈,导致输出性能数据不适用,自己看了不合理,别人看了也一头雾水,好在压测本来就是个精细且麻烦的活,大家也不会太计较
有点舍近求远,为了那点醋包一顿饺子。阵仗很大,结果生成了几行 python requests 代码
没有问题就是服务器
头衔自动化测试,主要开发服务器性能测试平台,以及做服务器性能测试,服务器性能测试是我的强项。其他也做过,难以落地。
都不容易,晋升真的大多时候看关系,再加上我这个人性格比较直,虽然不得罪人,但是不会主动攀关系。我也是默默做自己的项目,从 18 年维护至今,最初目标为开源项目,到后来又做闭源商业项目,倒不是想以此赚多少钱,只是想从不同的角度去思考项目的迭代方向,其中经历大大小小多次重构,收获颇多。现在处境也颇为尴尬,但目前的公司和我的项目匹配度很高,可以让我在实践中完善功能,所以继续待着。将来离开这个行业,说不定这就是我唯一能留下的东西了