1
Kinnice 2021-10-20 16:12:27 +08:00
服务器用的什么 CPU,用的什么内存,用的什么硬盘,带宽多少,你知道的其他框架在同等规模的结果
都未知 |
3
Kinnice 2021-10-20 16:32:41 +08:00
把[写入 redis]去掉 ,直接返回成功
|
5
Zhuzhuchenyan 2021-10-20 22:55:17 +08:00
最近也在做类似的事情,可以参考一下我的方法论
1. 时间指标 - 平均响应时间 - 最大响应时间,用来衡量极端情况下的用户承受的最大延迟 - 方差,标准差,用来衡量用户承受延迟的分布 - 有能力的话可以做一个直方图,并不需要全量记录,个人感觉取 1%抽样就足够了 2. 内存指标 我用的是.net core, 一些概念可能和 java 不一样,可以类比下 - GC 次数,特别是不同代的 GC 次数 - GC 时间占总执行时间的比例 - 若是 GC 次数不正常,可以考虑间隔每段时间取堆内存的 snapshot,若是工具支持,最好可以拿到内存分布的热点图,比如这个函数这一行分配了全体的 90%的内存 在有以上数据的情况下,即使没有同类型的框架可以横向比较,也可以自己根据压测结果优化迭代,再行压测比较。 |
6
Zhuzhuchenyan 2021-10-20 23:07:03 +08:00
然后探讨下你叙述中显露出的一些问题,仅供参考
1. “登录 1000 人,每个客户端每 20ms 给服务器发送一条测试消息,长度为 10 的字符串” 不知道你的游戏框架的序列化是怎么做的,若是想要反映真实情况,仅仅用字符串来模拟肯定是不够的,建议在压测环境中引入序列化和反序列化,这样可以更多暴露出在这个过程中的内存、CPU 问题 2. “每个客户端每 20ms 给服务器发送一条测试消息” 不建议给 20ms 间隔,每个客户端直接将单个 TCP 链接打满更具备压测意义 3. “10 多分钟开始客户端大批掉线” 不知道你客户端掉线的原因是什么,若是用 TCP 的话,最好可以知道连接断开的原因然后具体分析,正常情况下掉线一定是不正常的 最后, 若是你的序列化方案就是字符串序列化,而又不想自己写压测逻辑的话,可以考虑用你的服务器结构实现一个最简单的 HTTP Server,然后用成熟的 HTTP 压测工具去压,这个不具备任何业务逻辑,但是能很好暴露出你潜在的服务器处理能力。 这里我用的 wrk, 可以参考一下我在 MacBook Pro (16-inch, 2019) 2.3 GHz 八核 Intel Core i9 下的结果, wrk -c 400 -t 4 -d 5 http://localhost:13023/ Running 5s test @ http://localhost:13023/ 4 threads and 400 connections Thread Stats Avg Stdev Max +/- Stdev Latency 3.11ms 1.25ms 38.01ms 88.82% Req/Sec 20.08k 2.02k 23.81k 83.33% 407661 requests in 5.10s, 60.65MB read Socket errors: connect 153, read 101, write 0, timeout 0 Requests/sec: 79880.37 Transfer/sec: 11.88MB |
7
ggsl OP @Zhuzhuchenyan 好的,这就着手准备搞起,感谢分享!
|
8
q428202849 2021-10-22 13:51:09 +08:00
需要服务器吗 老板
|