后端就是增删改查，简单得一批

估计用别人库二开没付费

无他，异步或者轮训

我已经分解成四个测试需求了，分别测试的话用例和配置都是不一样的。我没有用过 jmeter，我都是用自己开发的工具进行测试，所以我都不关心线程数量，只关心用户数和业务，参见这个 https://testerhome.com/topics/39936，有兴趣可以研究下

不要被客户描述欺骗了，这是四个需求，需要分别测试
1.客户想知道订单处理 TPS，大于 250 每秒为合格
2.客户想知道每天 10 万的数据量系统如何表现，无异常为合格
3.客户想知道系统能支持多少人同时使用，1000 人为合格
4.客户想知道 100 万人次的数据量系统如合表现，无异常为合格

这么做的目的是什么？

根据你的需求这是最优的解决方式。我做压测也有类似输出每个用户日志流的需求，但是我的方法是在日志行默认输出用户编号，查看的时候进行筛选

输出到不同文件里面不就行了

居然还在纠结这个问题，我的话一定是 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 代码

没有问题就是服务器

头衔自动化测试，主要开发服务器性能测试平台，以及做服务器性能测试，服务器性能测试是我的强项。其他也做过，难以落地。

都不容易，晋升真的大多时候看关系，再加上我这个人性格比较直，虽然不得罪人，但是不会主动攀关系。我也是默默做自己的项目，从 18 年维护至今，最初目标为开源项目，到后来又做闭源商业项目，倒不是想以此赚多少钱，只是想从不同的角度去思考项目的迭代方向，其中经历大大小小多次重构，收获颇多。现在处境也颇为尴尬，但目前的公司和我的项目匹配度很高，可以让我在实践中完善功能，所以继续待着。将来离开这个行业，说不定这就是我唯一能留下的东西了

如果我来设计，那我会分两部分设计一个接口管理端，一个自动化执行引擎。接口管理端为从文件导入接口文档，手动维护接口依赖信息（人工维护），根据接口依赖生成冒烟用例。自动化引擎部分读取并按步骤执行用例，通过接口映射函数来处理对应接口参数和业务逻辑（人工维护）。这样整体维护的成本并不高，灵活性也好。因为是冒烟测试，全部用正常参数即可，需要异常参数那就是另一套设计了。

测试这条路提升太难了，大多都是小公司，项目不稳定，很难形成技术沉淀，我已经两年没长工资了，稳定在现在的公司，专做游戏服务器性能测试，目前已经形成自己的一套理论和工具，但不会推广，接下来准备转管理，顺便推广自己的理论和方法

每秒登陆 500 个我倒是没有仔细探究瓶颈在哪里，毕竟大多数项目不需要这么高的并发登陆数量。我设计压测工具完全是我自己研发的类似于服务器常用的 actor 架构网络底层，使用毫秒级定时器驱动用户执行，无论模拟多少个用户，线程数量始终等于 CPU 核数，避免使用一个线程模拟一个用户导致线程太多带来线程切换的开销，从而大大提升 CPU 效率

是的，但是转发消息之前，会通过 socks5 协议，协商代理验证方式以及代理的连接目标，一旦双向连接建立，就是按你说的那样工作。这其中有一个很重要的角色，是代理客户端，它可能是软件内置的，也可能是通过 hook 目标客户端进行工作，不同平台有不同成熟的工具软件

有意思，可惜我的工具目前不支持 mqtt 协议，我也一直想写 mqtt 的扩展，只是没有项目用来实践，技术栈用的 C++/lua，通信底层支持 tcp、udp、ssl、kcp，应用层支持 http、websocket、sproto、protobuf，想着继续完善下去
项目地址：https://gitee.com/lutianming/supersheeps_extend.git