Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
109 changes: 80 additions & 29 deletions docs/guides/benchmark_test.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ sidebar_position: 4

综合这两种测试程序,程序B主要用于模拟大量用户同时在线并进行消息交互,以增加服务器的负荷;而程序A则用于加载IMSDK,通过抽样统计来评估消息的可靠性和时延。两种程序的联合使用可以更好地模拟真实用户场景,并客观地提供IMSDK的测试报告。这种双重测试策略确保了从不同角度对系统进行全面的评估和验证。

## 可靠性和时延
## 可靠性和时延测试

消息的可靠性通常指的是消息投递的可靠性,即所谓的“消息必达”。这意味着一旦消息被发送,它必须能够被接收者成功收到。考虑到网络环境的复杂性和用户在线状态的不确定性,消息的可靠性无疑成为IM系统的一个核心性能指标,也是实现上的一大挑战。通常所说的IM系统的“可靠性”,主要是指聊天消息的投递可靠性。需要说明的是,这里的“消息”是广义的,包括用户看不见的各种指令和通知,如进群退群通知、好友添加通知等。

Expand Down Expand Up @@ -46,7 +46,7 @@ sidebar_position: 4
| **测试目的** | 少量用户情况下测试消息可靠性和耗时 |
| **用户数量** | 200用户,其中100人立刻登录,另外100个延迟登录 |
| **群数量及规模** | 每人加入0-10个常规群,群成员人数为5人 |
| **发消息频率** | 峰值150条/s |
| **发消息频率** | 峰值40条/s |
| **消息总数** | 112350 |
| **消息完整性** | 100%(所有消息精准送达) |
| **消息平均时延** | 0.231秒 |
Expand All @@ -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秒 |
Expand Down Expand Up @@ -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`:导入好友
Expand Down Expand Up @@ -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长连接。
Loading