我也对类似的项目做过性能测试,也是广播特别多,也是做了九宫格方案的优化,听起来似曾相识,我们还用了 kcp 通信,同场景从 30 多人优化到 100 多,不过后来那个项目中途砍掉了,感谢分享,我有很多游戏服务器性能测试积累,但是不爱写文字
一分钟 2000?我们的项目一秒钟 500 个登录没有问题。一分钟 4 万协议?我们的压测框架一秒钟就能处理一万条。看你的数据倒是给了我不少信心,原来我设计框架的也很强,对了我的技术是 c++ 嵌套 lua,也是 sproto 协议,好处是服务端客户端的 lua 代码可以拿来直接用
不做单接口,登陆查询剩余课程选课一起测试,这才符合真实场景
我这个是针对游戏服务器的,针对 tcp、udp、kcp、ssl 长连接,http、websocket、自定义 rpc 均可以。不过我真做服务器性能测试,你做接口自动化,用途不一样,设计细节上有很大差别,核心原理倒是一致。
我的服务器压力测试工具就是这个原理,用例生成快,不过我的接口前置和响应逻辑都是编写代码来处理,代码很少,处理很灵活
tps 翻译一下就是每秒处理的事务数量,跟响应时间没有必然联系,因为响应时间的成分非常复杂,响应时间=网络传输时间 + 系统排队时间 +cpu 处理时间。理论上 tps=1 秒/cpu 处理时间,但是 cpu 处理时间需要在业务上打点计时。所以直接发送大量强求,降低网络传输时间和系统排队时间带来的误差,这时 tps=总请求数/总耗时。
带宽上压测系统带宽大于等于被测系统,这样才能排除压测系统带宽限制带来的影响。从我的习惯来看,我总是申请 2 倍于被测系统的资源用于构建压测系统,各方面资源都留足余量,避免压测系统资源限制带来的瓶颈。
10m 带宽也敢用来做压力测试?内网直接 1000M 带宽,外网直接 200M 起步
你说的 token 应该也是附在 cookie 里面的,或者是一块 http 头信息,也有可能是 http 正文中携带,主要看你们的系统怎么设计的,这个可以问开发。如果你生成了 50 个账号的 token,那你发送 50 个下单接口请求,每个请求都要带上账号 token。你的程序框架可能是用一个线程模拟一个用户,那就是启动 50 个线程。
我的做法是自动注册账号并登录,然后下单购买,不同用户生成唯一账号是靠框架支持,如果注册登录接口的性能非常差,可以做类似集合点的东西,我用的框架没有这类设计,但是可以做到。如果真的不想调用注册登录接口,那就只能先准备足够多的账号并登录,记录下该账号登录后的 cookie,下单接口携带 cookie 即可
我目前算是专职服务器性能测试吧,游戏公司,有自己的一套针对游戏业务进行场景模拟的测试理论和技术框架,能熟练完成这项工作,已经和一个熟练的服务端开发差不多了,高并发网络编程,各种协议序列化,这算是基本技能。主要任务维护压测环境,完成施压和输出性能指标和服务器异常,性能瓶颈分析和调优当然交给开发。完成这些工作的前提是你得有一个高效且稳定的测试框架,确保瓶颈只会发生在服务器,而不是你的施压机器,分布式可以提高性能但会让整个压测系统更加复杂。
问这个问题的一般都是没有好用的工具,用例编写困难。不如说一下你的项目,以及涉及到的场景
应该压测工具直连 redis,执行 redis 命令
你这个跟压测 redis 有什么关系,你这是压测 flask
第一次完整的接口测试有用,测试过的接口再做接口自动化没有意义,但是接口自动化升级改造为压力测试就有用了
我的方法是,直接依靠录制回放的压测系统,根据功能场景,一个一个模块的测试。因为是录制的用例,参数都是带好的,大多不需要修改,不需要对着接口文档问开发每个参数是什么意思,只需要修改影响流程的关键参数即可让压测跑起来,简单有效。
2 周 gc 一次,几个小时 gc 一次,不敢想象。没用过 Java,只用过 lua,而我 10 秒就要 gc 一次,高并发下感受不到 gc 带来的卡顿
单接口测试简单得不能再简单了
问题太多,给你一个做性能的 https://gitee.com/lutianming/httpsupersheeps.git,我是作者,有什么问题联系我
使用代理的方式可以利用现有的客户端保持用户状态,可以轻松触达任意场景,自己做一个瘦客户端的话,登陆验证,状态维护,都是很麻烦的事。当然如果你们使用无状态的协议那没必要使用代理。
有点意思,我也做性能测试工具,借鉴借鉴