交付总览/压测报告
并发能力是压出来的
这一页放的是压测工具跑出来的原始数据：加压到 45.3 万连接的逐轮结果、QPS 与 P99 延迟、各个在线量级下的内存与 CPU 占用。测试环境、工具、日期和前提都写在下面，压测工具随源码交付，你可以用同一套流程在自己的机器上复核。
稳定连接 453,827 条 HTTP QPS 20,781 P99 29.5 ms
压测报告
45.3 万连接，是一轮一轮压上去的
下面每个数字都来自 im-benchmark 的实际运行结果，不是推算。这份报告的前提条件写得比数字还细 —— 脱离环境的性能数字没有意义。
测试环境
服务器8 核 CPU / 15.1 GB 内存
服务端与压测工具跑在同一台机器上，共享这 8 个核心。这个前提直接影响后面的建连速率。
WebSocket 极限连接测试
从 500 逐步加压到 50 万，每一轮失败率超过 30% 就自动停止。最后一轮目标 50 万，实际稳定挂住 453,827 条长连接。
5005000%7,046/s
5 万连接之后建连速率从 11,112/s 掉到 1,980/s，是因为服务端和压测工具把这 8 个核抢满了，CPU 到 100%。已经建立的连接没有掉线，掉的只是继续加压的速度。
综合评测
吞吐与延迟是另一组场景单独测的，和上面那张连接表不是同一轮。两个数字不能相乘理解。
HTTP API 并发
QPS 20,781 · P50 5.8ms · P99 29.5ms
各在线量级的资源占用
这张表比连接上限更有用 —— 它回答的是「我这台机器现在扛着多少人、还剩多少余量」。
5 万约 2.5 GB约 70%稳定
每条连接约占 30KB 内存：2 个 goroutine，加读写各 8KB 缓冲，加 256 条发送通道。
05 / 口径
这份报告怎么读
下面这几条决定了上面的数字该怎么用。写出来是因为：能把边界讲清楚的性能数据，才是能拿去做决策的性能数据。
- 测的是连接保持能力，不是同时聊天的人数。