7
请教大家服务器压力测试的问题
source link: https://www.v2ex.com/t/809247
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
目前手里有个简单的 java 游戏服框架，我进行的压测是登录 1000 人，每个客户端每 20ms 给服务器发送一条测试消息（长度为 10 的字符串），服务器写入 redis，并返回成功；客户端不管服务器返回，一直发送。
得出结果是服务器每秒能够处理 1600 次，cpu 占用 50%左右，内存飙升 2g，10 多分钟开始客户端大批掉线。
请问大家我的测试方法对吗？这个结果能不能说明这个框架性能不好呢？谢谢各位
服务器是 4 核 cpu
得出结果是服务器每秒能够处理 1600 次，cpu 占用 50%左右，内存飙升 2g，10 多分钟开始客户端大批掉线。
请问大家我的测试方法对吗？这个结果能不能说明这个框架性能不好呢？谢谢各位
服务器是 4 核 cpu
6 条回复 • 2021-10-20 23:07:03 +08:00
Zhuzhuchenyan 5 小时 1 分钟前
最近也在做类似的事情，可以参考一下我的方法论
1. 时间指标
- 平均响应时间
- 最大响应时间，用来衡量极端情况下的用户承受的最大延迟
- 方差，标准差，用来衡量用户承受延迟的分布
- 有能力的话可以做一个直方图，并不需要全量记录，个人感觉取 1%抽样就足够了
2. 内存指标
我用的是.net core, 一些概念可能和 java 不一样，可以类比下
- GC 次数，特别是不同代的 GC 次数
- GC 时间占总执行时间的比例
- 若是 GC 次数不正常，可以考虑间隔每段时间取堆内存的 snapshot，若是工具支持，最好可以拿到内存分布的热点图，比如这个函数这一行分配了全体的 90%的内存
在有以上数据的情况下，即使没有同类型的框架可以横向比较，也可以自己根据压测结果优化迭代，再行压测比较。
1. 时间指标
- 平均响应时间
- 最大响应时间，用来衡量极端情况下的用户承受的最大延迟
- 方差，标准差，用来衡量用户承受延迟的分布
- 有能力的话可以做一个直方图，并不需要全量记录，个人感觉取 1%抽样就足够了
2. 内存指标
我用的是.net core, 一些概念可能和 java 不一样，可以类比下
- GC 次数，特别是不同代的 GC 次数
- GC 时间占总执行时间的比例
- 若是 GC 次数不正常，可以考虑间隔每段时间取堆内存的 snapshot，若是工具支持，最好可以拿到内存分布的热点图，比如这个函数这一行分配了全体的 90%的内存
在有以上数据的情况下，即使没有同类型的框架可以横向比较，也可以自己根据压测结果优化迭代，再行压测比较。
Zhuzhuchenyan 4 小时 50 分钟前
然后探讨下你叙述中显露出的一些问题，仅供参考
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
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
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK