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

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

  • 居然还在纠结这个问题,我的话一定是 abcd 一起测试,但是我会模拟客户端的请求顺序和频率,也就是完全模拟客户端的行为,构建真实场景测试结果自然接近真实数据。

  • 我开发的压测工具底层使用 c++,业务层可以是 lua,python ,golang。python 现在是我准备抛弃的方案了,性能弱。准备再接入 js,引擎准备用 jerryscript

  • 这个时候你需要一个可编程的压测工具,很简单的功能用 Jmeter 反而复杂了

  • 结贴 at 2024年02月25日

    很感兴趣,楼主是帮忙内推吗 ?

  • 对的,就 jmeter 而言,多做几次你就发现会有一个单机效率最高的线程数量配置区间,也就是网友总结出来的大概 1000 到 3000 个线程,具体跟 CPU 性能相关,以此为基础进行分布式扩展

  • 通常并发是指 1 秒钟之内发出的请求数,单线程也可以并发上千上万,跟线程数量没有必然关系。因为 jmeter 用线程模拟用户,线程在 cpu 上的切换也需要消耗时间,剩下的才是实际执行逻辑运算的时间,线程越多切换时间就越多,实际执行逻辑运算的时间就越少,真正能并发多少个线程不是固定的,受线程中 IO 阻塞时间而定,而 IO 又是十分耗时且不稳定的,所以 jmeter 很难计算一个最具有效率的线程数量。压测过程实际并发数只能通过执行过程中进行统计

  • 线程太多,大量的 CPU 时间都用在了线程切换上,实际并发数量并不等于线程数量

  • 压测经验理论大多千篇一律,没什么好讲。做为一个有游戏服务器压测落地经验的大概说一下压测的几个作用:1。发现系统缺陷,用户多运行时间长时能发现一些很难发现又很严重的 bug;2.描述技术性能,服务于开发的一些性能指标数据,如接口响应时间;3.描述业务性能,老板最关心的指标,如最大承载用户,我就遇到过开发临时无法优化代码的情况下通过修改产品设计来达到需求。很多人把技术性能和业务性能混为一谈,导致输出性能数据不适用,自己看了不合理,别人看了也一头雾水,好在压测本来就是个精细且麻烦的活,大家也不会太计较

  • 有点舍近求远,为了那点醋包一顿饺子。阵仗很大,结果生成了几行 python requests 代码

  • 没有问题就是服务器

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

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

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

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

  • 游戏服务端性能测试 at 2023年09月13日

    每秒登陆 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

  • 游戏服务端性能测试 at 2023年08月22日

    我也对类似的项目做过性能测试,也是广播特别多,也是做了九宫格方案的优化,听起来似曾相识,我们还用了 kcp 通信,同场景从 30 多人优化到 100 多,不过后来那个项目中途砍掉了,感谢分享,我有很多游戏服务器性能测试积累,但是不爱写文字

  • 游戏服务端性能测试 at 2023年08月22日

    一分钟 2000?我们的项目一秒钟 500 个登录没有问题。一分钟 4 万协议?我们的压测框架一秒钟就能处理一万条。看你的数据倒是给了我不少信心,原来我设计框架的也很强,对了我的技术是 c++ 嵌套 lua,也是 sproto 协议,好处是服务端客户端的 lua 代码可以拿来直接用

  • 仅楼主可见
  • 不做单接口,登陆查询剩余课程选课一起测试,这才符合真实场景

  • 我这个是针对游戏服务器的,针对 tcp、udp、kcp、ssl 长连接,http、websocket、自定义 rpc 均可以。不过我真做服务器性能测试,你做接口自动化,用途不一样,设计细节上有很大差别,核心原理倒是一致。

  • 我的服务器压力测试工具就是这个原理,用例生成快,不过我的接口前置和响应逻辑都是编写代码来处理,代码很少,处理很灵活