feat: large group

docs/guides/benchmark_test.mdx

@@ -79,30 +79,68 @@ sidebar_position: 4
 | **抽样统计消息平均时延**       | 0.202秒                                     |
 | **抽样统计消息最大时延**       | 3.641秒                                     |
 
-#### 测试三：5万在线用户+5万大群
+#### 测试三：10w人大群
 
-测试程序B：模拟5万在线用户，随机发送消息
+> 以下数据为**商业版OpenIM**测试结果
 
-测试程序A：模拟20个用户，其中16个立刻登录，向10个5万人群聊、好友发送消息
+##### 代码修改：
 
-测试程序A注册10万用户：go run main.go -reg -u 100000
+- 测试程序A在` internal/group/notification.go `文件中，搜索`case constant.MemberInvitedNotification:`，注释掉此`case`中的内容，防止建群时测试程序A压力过大。
+- 测试程序A在`internal/group/group.go`文件中，搜索`syncer.WithNotice[*model_struct.LocalGroupMember, group.GetGroupMemberListResp`，找到下方`switch state`，注释掉`case`块`case syncer.Insert`中的内容，防止建群时测试程序A压力过大。
+- 测试程序B在`internal/interaction/long_conn_mgr.go`中，找到`handleMessage`方法，在函数名下方直接加上`return nil`，减少测试程序B收到消息压力。
+
+此次测试使用了5台64核128G服务器，分别用来部署4个测试程序B和1个服务端，1台16核32G服务器部署测试程序A。都使用内网连接。
+
+##### 运行：
+
+测试程序B：模拟10万在线用户，几乎不发送消息
+
+测试程序A：模拟20个用户，其中20个立刻登录，向1个10万人群聊、好友发送消息
+
+测试程序A注册20万用户：go run main.go -reg -u 200000
+
+测试程序A创建1个大群，11w群成员：go run main.go -lgr 1 -imf -crg -ckgn -ckcon -u 20 -su 1 -lg 1 -cg 0 -lgm 110000 -msgitv 40 -gm 5000 -sm 0
+
+创建完群聊之后，每一个测试程序B启动2.5万在线用户：
+
+- go run main.go -o 25000 -s 11 -e 25011 -c 1000 -i 500000 -rs 1000 -rr 1000
+- go run main.go -o 25000 -s 25011 -e 50011 -c 1000 -i 500000 -rs 1000 -rr 1000
+- go run main.go -o 25000 -s 50011 -e 75011 -c 1000 -i 500000 -rs 1000 -rr 1000
+- go run main.go -o 25000 -s 75011 -e 100011 -c 1000 -i 500000 -rs 1000 -rr 1000
+
+打开`Grafana`并配置好数据源和仪表盘，确认10w用户登录完毕之后，再启动测试程序A：
+
+测试程序A统计消息完整性和时延：go run main.go -lgr 1 -sem -ckmsn -u 20 -su 1 -lg 1 -cg 0 -lgm 110000 -msgitv 40 -gm 5000 -sm 0
 
-测试程序B启动5万在线用户：go run main.go -o 50000 -s 49500 -e 99500 -c 100 -i 500 -rs 1000 -rr 1000
+此时，测试程序A部署在服务器的共享内存/dev/shm上
 
-测试程序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上
+| 参数/结果                      | 描述                                                         |
+| ------------------------------ | ------------------------------------------------------------ |
+| **压力情况**                   | 100000用户在线，每秒发送约200条消息，推送消息频率为2000w条/s |
+| **抽样统计用户数**             | 20用户，其中20人立刻登录                                     |
+| **抽样统计用户的群数量及规模** | 1个大群，每个群110000人，其中10010人在线                     |
+| **抽样统计消息发送频率**       | 峰值200条/s                                                  |
+| **抽样统计消息数**             | 190w                                                         |
+| **抽样统计消息完整性**         | 100%（所有消息精准送达）                                     |
+| **抽样统计消息平均时延**       | 0.805秒                                                      |
+| **抽样统计消息最大时延**       | 3.772秒                                                      |
 
-| 参数/结果                      | 描述                                      |
-| ------------------------------ | ----------------------------------------- |
-| **压力情况**                   | 50000用户在线，每秒发送约1700条消息       |
-| **抽样统计用户数**             | 20用户，其中16人立刻登录，另外4个延迟登录 |
-| **抽样统计用户的群数量及规模** | 10个大群，每个群50000人，其中500人在线    |
-| **抽样统计消息发送频率**       | 峰值32条/s                                |
-| **抽样统计消息数**             | 24000                                     |
-| **抽样统计消息完整性**         | 100%（所有消息精准送达）                  |
-| **抽样统计消息平均时延**       | 0.022秒                                   |
-| **抽样统计消息最大时延**       | 1.664秒                                   |
+##### 资源消耗：
+
+此场景下，服务端的资源消耗峰值为：
+
+- CPU：48.81%（约31核+）
+- 内存：11.06%（约14.15G）
+- 出网带宽：11.158Gibit/s
+- 入网带宽：252.372Mibit/s
+
+测试程序B的服务器的主要资源消耗峰值为：
+
+- CPU：38.01%（约24核+）
+
+以上数据仅供参考。
 
 #### 测试二服务器资源消耗
 
@@ -357,6 +395,11 @@ go run main.go -test -u 10 -su 3 -lg 2 -cg 4 -cgm 5 -sm 6 -gm 7 -msgitv 1000 -re
 
 ### **注意事项**
 
+运行测试程序，需要注意以下事项避免影响结果：
+
+1. 测试程序和服务端应使用内网连接，避免网络影响。
+2. 测试程序A应该部署在内存文件系统上（此测试中为/dev/shm），避免磁盘读写开销。
+
 #### **限制修改**
 
 - 在模拟操作过程中，多个 SDK 实例同时运行，可能会对服务器造成较大压力，进而引发超时或其他问题。为确保系统在进行大规模数据量测试时能够平稳运行，需对以下几个关键指标进行调整：
@@ -369,7 +412,7 @@ go run main.go -test -u 10 -su 3 -lg 2 -cg 4 -cgm 5 -sm 6 -gm 7 -msgitv 1000 -re
      - 位置：`openim-sdk-core/pkg/common/trigger_channel.go`
      - 调整内容：找到`const timeout`，将管道超时时间适当调大。
      - 原因：模拟大量sdk接受服务端数据时，会对服务器造成较大压力，超时大多是因为sdk压力过大而非服务端，因此不会影响测试服务端性能的结果。
-  
+
   3. **服务端通知超时时间**
      - 位置：`open-im-server/pkg/notification/msg.go`
      - 调整内容：搜索`WithTimeout`，将`context`超时的时间适当调大。
@@ -393,7 +436,7 @@ go run main.go -test -u 10 -su 3 -lg 2 -cg 4 -cgm 5 -sm 6 -gm 7 -msgitv 1000 -re
 
   7. **动态端口范围**
 
-     - 运行命令（选择下面其一即可）：
+     - 运行测试程序B的服务器中运行命令（选择下面其一即可）：
 
        - 当前会话：`sudo sysctl -w net.ipv4.ip_local_port_range="10000 65000"`
 
@@ -410,3 +453,9 @@ go run main.go -test -u 10 -su 3 -lg 2 -cg 4 -cgm 5 -sm 6 -gm 7 -msgitv 1000 -re
          ```
 
      - 原因：保证有足够的动态端口数模拟sdk长连接。
+
+  8. 打开全量在线缓存
+
+     - 在`open-im-server`的`config/openim-push.yml`中，找到`fullUserCache`设置为`true`
+     - 原因：此功能会占用更多内存，但是能够提高运行效率。
+