录制一个用例登录是最基本的，登录后其他操作可以一并录制，取决于你的游戏有什么功能，例如抽卡、查看邮件、战斗打怪、装备强化等等

有 lua 基础，游戏服务器性能建议你学下我这个 https://gitee.com/lutianming/OpenSheeps

jemter 这么难用想不通为啥那么多人研究

数据包是一个 8 个字节的数据，你拼成字符串显然超过 8 个字节，你应该先搞懂字符编码

模拟大量用户涌入进行业务操作不就行了，然后对代码进行 cpu 缓存级别的优化

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

估计用别人库二开没付费

无他，异步或者轮训

我已经分解成四个测试需求了，分别测试的话用例和配置都是不一样的。我没有用过 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 年维护至今，最初目标为开源项目，到后来又做闭源商业项目，倒不是想以此赚多少钱，只是想从不同的角度去思考项目的迭代方向，其中经历大大小小多次重构，收获颇多。现在处境也颇为尴尬，但目前的公司和我的项目匹配度很高，可以让我在实践中完善功能，所以继续待着。将来离开这个行业，说不定这就是我唯一能留下的东西了