性能与可靠性报告
使用测试程序模拟大量用户在线与消息收发，评估容量与链路稳定性。
OpenIMSDK 压力与可靠性测试
名词与测试范围
- OpenIMSDK：项目统称，包含客户端 SDK OpenIMClientSDK 与服务端 OpenIMServer。
- ChatServer：业务扩展服务端。除非另有说明，本页的 OpenIMServer 核心性能测试不包含 ChatServer。
- 应用管理员：用于获取令牌、批量操作等管理端 API 调用的管理员账号。
- 应用业务服务端：接入 OpenIMServer 的业务后端，负责业务逻辑，并通过 API、回调或 SDK 与即时通讯系统集成。
测试背景
OpenIMSDK 不是 WeChat、Slack 一类可直接使用的聊天应用，而是一套由 OpenIMClientSDK 与 OpenIMServer 组成的即时通讯解决方案。OpenIMClientSDK 底层依赖使用 Go 编写的 openim-sdk-core，使用大量真实设备进行可重复测试并不现实，因此本次测试通过程序模拟大规模在线连接和消息流量，用于评估系统容量、可靠性与时延。
测试由两个程序配合完成：
- 测试程序 A：
openim-sdk-core/integration_test（可靠性、时延与一致性验证） - 加载并运行
openim-sdk-core实例来模拟 OpenIMClientSDK，覆盖较完整的客户端处理链路。 - 测试程序 B：
openim-sdk-core/msgtest（压力与容量测试） - 重点模拟登录和消息收发，通过大量实例构造高并发压力场景。
建议由 msgtest 生成压力负载，再由 integration_test 抽样验证可靠性与时延。
可靠性与时延定义
- 可靠性：指消息投递的可靠性，即发送的消息必须由接收方成功接收。
- 时延：指客户端 A 创建并发送消息，到客户端 B 成功接收并持久化该消息所经过的时间。
测试资源
服务器 1：Ubuntu 22.04.2，16 核 CPU、64 GB 内存、150 GB 机械硬盘。用于部署依赖组件和 OpenIMServer，同时运行测试程序 B；测试程序 A 也可部署在共享内存 /dev/shm 中。
服务器 2：Ubuntu 18.04.5，4 核 CPU、8 GB 内存、40 GB 机械硬盘。用于在共享内存 /dev/shm 中运行测试程序 A。
服务端配置文件 open-im-server/start-config.yml 中，将实例数调整为 openim-push: 8、openim-msgtransfer: 8，其他服务保持 1 个实例。
测试场景与结果
测试一：200 个用户
测试程序 A 模拟 200 个用户，其中 100 个用户立即登录，并向好友和小规模群聊发送消息。
运行命令：
go run main.go -lgr 0.5 -imf -crg -ckgn -ckcon -sem -ckmsn -u 200 -su 10 -lg 2 -cg 2 -cgm 5 -sm 5 -gm 5 -reg
测试程序 A 部署在服务器 1 的共享内存 /dev/shm 中。
| 参数或结果 | 说明 |
|---|---|
| 测试目的 | 验证小规模用户场景下的消息可靠性与时延 |
| 用户数量 | 200 个用户；100 个立即登录，100 个延迟登录 |
| 群聊数量与规模 | 每个用户加入 0～10 个普通群聊，每个群聊包含 5 名成员 |
| 消息发送速率 | 峰值 40 条/秒 |
| 消息总数 | 112,350 条 |
| 消息完整性 | 100%，全部消息准确送达 |
| 平均时延 | 0.231 秒 |
| 最大时延 | 1.703 秒 |
测试二：5 万在线用户与小规模群聊
- 测试程序 B 模拟 50,000 个在线用户随机发送消息，用于产生压力。
- 测试程序 A 模拟 100 个用户，用于抽样统计可靠性与时延。
示例命令：
- 测试程序 A 注册 100,000 个用户：
go run main.go -reg -u 100000 - 测试程序 B 启动 50,000 个在线用户：
go run main.go -s 49500 -e 99500 -c 100 -i 500 -rs 1000 -rr 1000 - 测试程序 A 执行抽样验证：
go run main.go -lgr 0.8 -imf -crg -ckgn -ckcon -sem -ckmsn -u 100 -su 3 -lg 0 -cg 4 -cgm 5 -sm 100 -gm 100 -msgitv 1500 -test
测试程序 A 部署在服务器 2 的 /dev/shm 中，测试程序 B 部署在服务器 1。完整测试约需 4 小时；如只需快速验证，可相应缩小数据规模。
| 参数或结果 | 说明 |
|---|---|
| 压力负载 | 50,000 个用户在线，约 1,700 条消息/秒 |
| 抽样用户数量 | 100 个用户；80 个立即登录，20 个延迟登录 |
| 抽样群聊数量与规模 | 每个用户加入 0～20 个普通群聊，每个群聊包含 5 名成员 |
| 抽样消息发送速率 | 峰值 54 条/秒 |
| 抽样消息数量 | 170,800 条 |
| 抽样消息完整性 | 100%，全部消息准确送达 |
| 抽样平均时延 | 0.202 秒 |
| 抽样最大时延 | 3.641 秒 |
测试二的服务器资源消耗
在线用户数：
消息压力（图中指标表示服务器每分钟接收的消息量）：
CPU 使用情况：
| 进程 | CPU 占用 |
|---|---|
| openim-msggateway | 210% |
| mongo | 100% |
| kafka | 84% |
| redis | 67% |
| openim-rpc-msg | 56% |
| openim-msgtransfer | 27% × 8 |
| openim-push | 13% × 8 |
| 其他 OpenIMServer 服务与组件 | 65% |
| 总计 | 902% |
物理内存占用情况：
| 进程 | 内存占用 |
|---|---|
| openim-msggateway | 2.1 GiB |
| mongo | 717 MiB |
| kafka | 1.1 GiB |
| redis | 85 MiB |
| openim-rpc-msg | 162 MiB |
| openim-msgtransfer | 74 MiB × 8 |
| openim-push | 126 MiB × 8 |
| 其他 OpenIMServer 服务与组件 | 457 MiB |
| OpenIMServer 全部服务与组件合计 | 6.986 GiB |
以上数据为近似统计，合计值不包含 Docker 向容器转发数据产生的额外开销。
测试三：5 万在线用户与 5 万人群聊
- 测试程序 B 模拟 50,000 个在线用户随机发送消息。
- 测试程序 A 模拟 20 个用户，其中 16 个立即登录，并向好友和 10 个 50,000 人群聊发送消息。
测试程序 A 注册 100,000 个用户：
go run main.go -reg -u 100000
测试程序 B 启动 50,000 个在线用户：
go run main.go -o 50000 -s 49500 -e 99500 -c 100 -i 500 -rs 1000 -rr 1000
测试程序 A 统计消息完整性与时延：
go run main.go -lgr 0.8 -imf -crg -ckgn -ckcon -sem -ckmsn -u 20 -su 3 -lg 10 -cg 0 -cgm 5 -sm 0 -gm 10
测试程序 A 部署在服务器 2 的 /dev/shm 中，测试程序 B 部署在服务器 1。
| 参数或结果 | 说明 |
|---|---|
| 压力负载 | 50,000 个用户在线，约 1,700 条消息/秒 |
| 抽样用户数量 | 20 个用户；16 个立即登录，4 个延迟登录 |
| 抽样群聊数量与规模 | 10 个 50,000 人群聊，每个群聊有 500 名成员在线 |
| 抽样消息发送速率 | 峰值 32 条/秒 |
| 抽样消息数量 | 24,000 条 |
| 抽样消息完整性 | 100%，全部消息准确送达 |
| 抽样平均时延 | 0.022 秒 |
| 抽样最大时延 | 1.664 秒 |
结果分析
在本页所述测试配置下，OpenIMServer 可支持 50,000 个用户同时在线和多个 50,000 人群聊。在每秒约 1,700 条消息的压力下，实测消息送达率为 100%，平均时延低于 1 秒，最大时延低于 3 秒。
以上结果仅代表指定版本、硬件、部署方式与测试模型下的实测数据，不应直接视为所有生产环境的容量承诺。上线前应根据实际用户行为、消息大小、存储方案和可用性目标重新压测。
配置建议
以 100,000 个注册用户、日常在线率 10%、支持 50,000 人群聊、每秒 600 条消息为估算基准，建议配置如下：
| 资源 | 建议配置 |
|---|---|
| 内存 | 16 GB |
| CPU | 8 核 |
| 网络带宽 | 10 Mbps |
消息包按 2 KB 估算，实际大小取决于消息内容；普通文本消息包通常约为 700 字节。压测程序的配置参数、运行步骤与注意事项，请参阅压测工具。