From b0970258dc625a84fed0da06c940c1c633136cd8 Mon Sep 17 00:00:00 2001 From: icey-yu <1186114839@qq.com> Date: Sun, 28 Sep 2025 11:24:39 +0800 Subject: [PATCH] feat: test --- docs/guides/benchmark_test.mdx | 109 ++++++++++++++++++++++++--------- 1 file changed, 80 insertions(+), 29 deletions(-) diff --git a/docs/guides/benchmark_test.mdx b/docs/guides/benchmark_test.mdx index 996eec1c44..b851592fa7 100644 --- a/docs/guides/benchmark_test.mdx +++ b/docs/guides/benchmark_test.mdx @@ -17,7 +17,7 @@ sidebar_position: 4 综合这两种测试程序，程序B主要用于模拟大量用户同时在线并进行消息交互，以增加服务器的负荷；而程序A则用于加载IMSDK，通过抽样统计来评估消息的可靠性和时延。两种程序的联合使用可以更好地模拟真实用户场景，并客观地提供IMSDK的测试报告。这种双重测试策略确保了从不同角度对系统进行全面的评估和验证。 -## 可靠性和时延 +## 可靠性和时延测试 消息的可靠性通常指的是消息投递的可靠性，即所谓的“消息必达”。这意味着一旦消息被发送，它必须能够被接收者成功收到。考虑到网络环境的复杂性和用户在线状态的不确定性，消息的可靠性无疑成为IM系统的一个核心性能指标，也是实现上的一大挑战。通常所说的IM系统的“可靠性”，主要是指聊天消息的投递可靠性。需要说明的是，这里的“消息”是广义的，包括用户看不见的各种指令和通知，如进群退群通知、好友添加通知等。 @@ -46,7 +46,7 @@ sidebar_position: 4 | **测试目的** | 少量用户情况下测试消息可靠性和耗时 | | **用户数量** | 200用户，其中100人立刻登录，另外100个延迟登录 | | **群数量及规模** | 每人加入0-10个常规群，群成员人数为5人 | -| **发消息频率** | 峰值150条/s | +| **发消息频率** | 峰值40条/s | | **消息总数** | 112350 | | **消息完整性** | 100%（所有消息精准送达） | | **消息平均时延** | 0.231秒 | @@ -62,16 +62,18 @@ sidebar_position: 4 测试程序B启动5万在线用户：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 +测试程序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上 +此时，测试程序A部署在服务器2的共享内存/dev/shm上，测试程序B部署在服务器1上。 + +> 测试二数据量较大，跑完需要大约4小时。如果希望更快出结果可以调小测试数据量。 | 参数/结果 | 描述 | | ------------------------------ | ------------------------------------------- | | **压力情况** | 50000用户在线，每秒发送约1700条消息 | | **抽样统计用户数** | 100用户，其中80人立刻登录，另外20个延迟登录 | | **抽样统计用户的群数量及规模** | 每人加入0-20个常规群，群成员人数为5人 | -| **抽样统计消息发送频率** | 峰值160条/s | +| **抽样统计消息发送频率** | 峰值54条/s | | **抽样统计消息数** | 170800 | | **抽样统计消息完整性** | 100%（所有消息精准送达） | | **抽样统计消息平均时延** | 0.202秒 | @@ -172,7 +174,7 @@ OpenIM 支持同时在线 5 万人，能够处理多个 5 万人超级大群， *备注：消息包大小按照2KB计算。实际消息包大小根据发送内容而异，常规的一句文字消息消息包大小为700字节左右。* -### **补充说明** +## **压测程序运行说明** 本次测试用到了两个测试程序： @@ -180,42 +182,47 @@ OpenIM 支持同时在线 5 万人，能够处理多个 5 万人超级大群， 可靠性测试程序，路径：`openim-sdk-core/integration_test/` +每一次运行压测程序，需要确保服务端和客户端初始数据都为空。服务端需要删除`components`文件夹并重启`docker`组件，客户端需要清楚数据库文件（默认在`integration_test/data`，`data`文件夹需要手动创建）。 + 以下是可靠性测试程序的使用说明以及检测逻辑的说明。 #### **参数说明** 测试程序支持通过配置参数来指定不同的测试场景。通过灵活设置参数，用户可以自由地模拟各种复杂场景，涵盖不同的网络状态和操作流程，从而更精确地评估消息通道的可靠性。 -| 参数 | 含义 | 类型 | -| ----- | -------------------------------- | ----- | -| u | 用户数量 | int | -| su | 拥有所有好友的用户数量 | int | -| lg | 包含大群的数量 | int | -| lgm | 大群人数 | int | -| cg | 每个人创建的常规群聊数量 | int | -| cgm | 常规群人数 | int | -| sm | 每人发送的私聊消息数量 | int | -| gm | 每人发送的群聊消息数量 | int | -| reg | 是否注册 | bool | -| imf | 是否导入好友 | bool | -| crg | 是否创建群组 | bool | -| sem | 是否发送消息 | bool | -| ckgn | 是否检查群组数量 | bool | -| ckcon | 是否检查会话数量 | bool | -| ckmsn | 是否检查消息数量 | bool | -| ckuni | 是否模拟卸载和重新安装并再次检查 | bool | -| lgr | 登录用户比例/登录率 | float | +| 参数 | 含义 | 类型 | +| ------ | ---------------------------------------------------------- | ----- | +| test | sdk是否运行测试模式，测试模式的sdk对于大量消息有更高容忍度 | bool | +| u | 用户数量 | int | +| su | 拥有所有好友的用户数量 | int | +| lg | 包含大群的数量 | int | +| lgm | 大群人数 | int | +| cg | 每个人创建的常规群聊数量 | int | +| cgm | 常规群人数 | int | +| sm | 每人发送的私聊消息数量 | int | +| gm | 每人发送的群聊消息数量 | int | +| msgitv | 发送消息间隔（单位：ms），群聊消息和单聊消息独立计算间隔 | int | +| reg | 是否注册 | bool | +| imf | 是否导入好友 | bool | +| crg | 是否创建群组 | bool | +| sem | 是否发送消息 | bool | +| ckgn | 是否检查群组数量 | bool | +| ckcon | 是否检查会话数量 | bool | +| ckmsn | 是否检查消息数量 | bool | +| ckuni | 是否模拟卸载和重新安装并再次检查 | bool | +| lgr | 登录用户比例/登录率 | float | 以下为一个运行命令的示例： ```bash -go run main.go -u 10 -su 3 -lg 2 -cg 4 -cgm 5 -sm 6 -gm 7 -reg -lgr 0.7 -imf -crg -ckgn -ckcon -sem -ckmsn -ckuni +go run main.go -test -u 10 -su 3 -lg 2 -cg 4 -cgm 5 -sm 6 -gm 7 -msgitv 1000 -reg -lgr 0.7 -imf -crg -ckgn -ckcon -sem -ckmsn -ckuni ``` 该命令的参数含义如下： +- `-test`：运行测试模式 - `-u 10`：总共创建10个用户 - `-su 3`：创建3个超级用户 - `-lg 2`：创建2个大群聊 @@ -223,6 +230,7 @@ go run main.go -u 10 -su 3 -lg 2 -cg 4 -cgm 5 -sm 6 -gm 7 -reg -lgr 0.7 -imf -cr - `-cgm 5`：每个小群聊包含5个成员 - `-sm 6`：发送6条私聊消息 - `-gm 7`：发送7条群聊消息 +- `-msgitv 1000`：每隔1000ms发送一条消息 - `-reg`：执行用户注册 - `-lgr 0.7`：70%的用户登录 - `-imf`：导入好友 @@ -347,15 +355,58 @@ go run main.go -u 10 -su 3 -lg 2 -cg 4 -cgm 5 -sm 6 -gm 7 -reg -lgr 0.7 -imf -cr 需要注意的是，只有申请发起人会收到好友申请通过的未读通知消息，且根据**导入好友**操作逻辑，只有超级用户的通知消息数量会有所不同。 +### **注意事项** + #### **限制修改** - 在模拟操作过程中，多个 SDK 实例同时运行，可能会对服务器造成较大压力，进而引发超时或其他问题。为确保系统在进行大规模数据量测试时能够平稳运行，需对以下几个关键指标进行调整： 1. **修改请求超时时间** - 位置：`openim-sdk-core/pkg/network/http_client.go` - - 调整内容：将请求的默认超时时间适当延长，以减少大数据量情况下的请求超时问题。建议根据测试规模和实际网络情况进行合理配置。 - 2. **设置通知消息未读状态** + - 调整内容：搜索`Timeout`，将请求的默认超时时间适当延长，以减少大数据量情况下的请求超时问题。建议根据测试规模和实际网络情况进行合理配置。 + - 原因：模拟大量sdk发起请求时，会对服务器造成较大压力，超时大多是因为sdk压力过大而非服务端，因此不会影响测试服务端性能的结果。 + + 2. **sdk异步管道超时时间** + - 位置：`openim-sdk-core/pkg/common/trigger_channel.go` + - 调整内容：找到`const timeout`，将管道超时时间适当调大。 + - 原因：模拟大量sdk接受服务端数据时，会对服务器造成较大压力，超时大多是因为sdk压力过大而非服务端，因此不会影响测试服务端性能的结果。 + + 3. **服务端通知超时时间** + - 位置：`open-im-server/pkg/notification/msg.go` + - 调整内容：搜索`WithTimeout`，将`context`超时的时间适当调大。 + - 原因：客户端和服务端在同一服务器会影响服务端性能，适当调大超时时间防止原本能正常传输的信息报错。 + + 4. **服务端日志级别** + - 位置：`open-im-server/config/log.yml` + - 调整内容：将服务端日志级别`remainLogLevel`设置为3。 + - 原因：服务端日志级别默认为`debug`级别，主要为开发测试使用，会对性能产生影响。 + + 5. **设置通知消息未读状态** - 位置：`open-im-server/config/notification.yml` - 调整内容：将 `groupCreated` 和 `friendApplicationApproved` 的 `unreadCount` 参数设置为 `true`。此配置将确保在线用户接收到群创建和好友申请通过的通知消息时，依然将其标记为未读消息，方便后续的未读消息数量计算。 - 3. **最大文件描述符数量** + - 原因：统一sdk未读数的计算逻辑。 + + 6. **服务端最大连接数量** + - 位置：`open-im-server/start-config.yml` - 调整内容：根据测试时需要登录的用户数量，将`maxFileDescriptors`的值适当变大。 + - 原因：保证服务端能接受足够多的长连接。 + + 7. **动态端口范围** + + - 运行命令（选择下面其一即可）： + + - 当前会话：`sudo sysctl -w net.ipv4.ip_local_port_range="10000 65000"` + + - 永久： + ```sh + # 1) 直接写入（追加）到 /etc/sysctl.conf + sudo bash -c 'echo "net.ipv4.ip_local_port_range = 10000 65000" >> /etc/sysctl.conf' + + # 2) 立刻生效 + sudo sysctl -p + + # 3) 验证 + cat /proc/sys/net/ipv4/ip_local_port_range + ``` + + - 原因：保证有足够的动态端口数模拟sdk长连接。