居然还在纠结这个问题,我的话一定是 abcd 一起测试,但是我会模拟客户端的请求顺序和频率,也就是完全模拟客户端的行为,构建真实场景测试结果自然接近真实数据。
我开发的压测工具底层使用 c++,业务层可以是 lua,python ,golang。python 现在是我准备抛弃的方案了,性能弱。准备再接入 js,引擎准备用 jerryscript
这个时候你需要一个可编程的压测工具,很简单的功能用 Jmeter 反而复杂了
很感兴趣,楼主是帮忙内推吗 ?
对的,就 jmeter 而言,多做几次你就发现会有一个单机效率最高的线程数量配置区间,也就是网友总结出来的大概 1000 到 3000 个线程,具体跟 CPU 性能相关,以此为基础进行分布式扩展
通常并发是指 1 秒钟之内发出的请求数,单线程也可以并发上千上万,跟线程数量没有必然关系。因为 jmeter 用线程模拟用户,线程在 cpu 上的切换也需要消耗时间,剩下的才是实际执行逻辑运算的时间,线程越多切换时间就越多,实际执行逻辑运算的时间就越少,真正能并发多少个线程不是固定的,受线程中 IO 阻塞时间而定,而 IO 又是十分耗时且不稳定的,所以 jmeter 很难计算一个最具有效率的线程数量。压测过程实际并发数只能通过执行过程中进行统计
线程太多,大量的 CPU 时间都用在了线程切换上,实际并发数量并不等于线程数量
压测经验理论大多千篇一律,没什么好讲。做为一个有游戏服务器压测落地经验的大概说一下压测的几个作用:1。发现系统缺陷,用户多运行时间长时能发现一些很难发现又很严重的 bug;2.描述技术性能,服务于开发的一些性能指标数据,如接口响应时间;3.描述业务性能,老板最关心的指标,如最大承载用户,我就遇到过开发临时无法优化代码的情况下通过修改产品设计来达到需求。很多人把技术性能和业务性能混为一谈,导致输出性能数据不适用,自己看了不合理,别人看了也一头雾水,好在压测本来就是个精细且麻烦的活,大家也不会太计较
有点舍近求远,为了那点醋包一顿饺子。阵仗很大,结果生成了几行 python requests 代码
没有问题就是服务器