Merge pull request #281 from icey-yu/fix-test

feat: test

Author: withchao

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,57 +174,63 @@ OpenIM 支持同时在线 5 万人，能够处理多个 5 万人超级大群，
 
 *备注：消息包大小按照2KB计算。实际消息包大小根据发送内容而异，常规的一句文字消息消息包大小为700字节左右。*
 
-### **补充说明**
+## **压测程序运行说明**
 
 本次测试用到了两个测试程序：
 
 压力测试程序，路径：`openim-sdk-core/msgtest/`
 
 可靠性测试程序，路径：`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个大群聊
 - `-cg 4`：每个登录用户创建4个小群聊
 - `-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长连接。