# Performance_Test

**Repository Path**: LordLaoZi/Performance_Test

## Basic Information

- **Project Name**: Performance_Test
- **Description**: 野火专业版IM服务性能测试
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 6
- **Created**: 2022-07-20
- **Last Updated**: 2022-07-20

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 野火专业版IM服务性能测试
本工程说明如何进行野火专业版IM服务性能测试，关于性能方面现有：单机百万连接测试、单聊消息测试、群聊消息测试和聊天室消息测试。

## 单机百万连接测试
单机百万连接测试在另外一个工程中，Github地址在[这里](https://github.com/wildfirechat/C1000K_Test)，码云地址在[这里](https://gitee.com/wfchat/C1000K_Test)。

## 单聊消息测试

使用腾讯云北京6区一台标准S6云服务器8C32G和一台云MySQL服务8C16G，测试结果如下：

### 发送测试：
测试方法：200个发送者，向1000个接收者发送消息，其中有1个观察用户手机登陆在线，其余接收者不在线，发送50轮。

| 内容 | 结果 | 说明 |
| ------ | ------ | ------ |
| 服务资源 | 16核48G| 云服务器和云MySQL硬件资源合计计算  |
| 发送条数 | 1000万 | 200个发送者，1000个接收者，发送50轮 |
| 成功率 | 100% | 所有消息都成功落库，观察者接收消息条数正确 |
| 发送延迟 | 肉眼无法察觉 | 发送结束后，观察者立即收齐消息。服务器压力迅速降为0 |
| 发送时间 | 509秒 |  |
| 发送速率 | 19646条/秒 |  |
| 发送单核速率 | 1227条/秒 | 发送测试速率除以核心数16 |
| 发送单核分发速率 | 2455条/秒 | 单聊测试的分发是2，所以是单核测试速度乘于2 |

### 收发测试：

测试方法：200个发送者，向1000个接收者发送消息，其中有1个观察用户手机登陆在线，其余接收者测试工具模拟在线实时接收消息，发送50轮。

| 内容 | 结果 | 说明 |
| ------ | ------ | ------ |
| 服务资源 | 16核48G| 云服务器和云MySQL硬件资源合计计算  |
| 收发条数 | 1000万 | 200个发送者，1000个接收者，发送50轮。1000个接受者在线实时接收消息 |
| 成功率 | 100% | 所有消息都成功落库，观察者接收消息条数正确 |
| 收发延迟 | 肉眼无法察觉 | 发送结束后，观察者立即收齐消息。服务器压力迅速降为0 |
| 收发时间 | 719秒 |  |
| 收发速率 | 13908条/秒 |  |
| 收发单核速率 | 869条/秒 | 发送测试速率除以核心数16 |

### 测试方法及测试视频
测试方法请看[这里](./single_message_test/)。

测试视频：

<a href="https://www.bilibili.com/video/bv1EY4y1n7iS"><img src="./single_message_test/bilibili_video_cover.png" alt="操作视频"></a>

## 群聊消息测试
使用腾讯云北京6区一台标准S6云服务器8C32G和一台云MySQL服务8C16G，测试结果如下：

### 百人群发送消息测试：
测试方法：50个发送者，向100个群里发送消息，每个群有49个普通成员，1个观察用户，还有这50个发送者，一共是100群成员。发送20轮。

| 内容 | 结果 | 说明 |
| ------ | ------ | ------ |
| 服务资源 | 16核48G| 云服务器和云MySQL硬件资源合计计算  |
| 发送条数 | 10万 | 50 * 100 * 20 |
| 成功率 | 100% | 所有消息都成功落库，观察者接收消息条数正确 |
| CPU利用率 | 100% | CPU利用率打满说明服务无瓶颈 |
| 发送延迟 | 肉眼无法察觉 | 发送结束后，观察者立即收齐消息。服务器压力迅速降为0 |
| 发送时间 | 74.6秒 |  |
| 发送速率 | 1340条/秒 |  |
| 发送单核速率 | 83.75条/秒 | 发送测试速率除以核心数16 |
| 发送单核分发速率 | 8375条/秒 | 单核测试速度乘于100 |

### 两百人群发送消息测试：
测试方法：100个发送者，向100个群里发送消息，每个群有99个普通成员，1个观察用户，还有这100个发送者，一共是200群成员。发送10轮。

| 内容 | 结果 | 说明 |
| ------ | ------ | ------ |
| 服务资源 | 16核48G| 云服务器和云MySQL硬件资源合计计算  |
| 发送条数 | 10万 | 100 * 100 * 10 |
| 成功率 | 100% | 所有消息都成功落库，观察者接收消息条数正确 |
| CPU利用率 | 100% | CPU利用率打满说明服务无瓶颈 |
| 发送延迟 | 肉眼无法察觉 | 发送结束后，观察者立即收齐消息。服务器压力迅速降为0 |
| 发送时间 | 145.8秒 |  |
| 发送速率 | 685.8条/秒 |  |
| 发送单核速率 | 42.87条/秒 | 发送测试速率除以核心数16 |
| 发送单核分发速率 | 8573条/秒 | 单核测试速度乘于200 |

### 千人群发送消息测试：
测试方法：100个发送者，向100个群里发送消息，每个群有899个普通成员，1个观察用户，还有这100个发送者，一共是1000群成员。发送2轮。

| 内容 | 结果 | 说明 |
| ------ | ------ | ------ |
| 服务资源 | 16核48G| 云服务器和云MySQL硬件资源合计计算  |
| 发送条数 | 2万 | 100 * 100 * 2 |
| 成功率 | 100% | 所有消息都成功落库，观察者接收消息条数正确 |
| CPU利用率 | 100% | CPU利用率打满说明服务无瓶颈 |
| 发送延迟 | 肉眼无法察觉 | 发送结束后，观察者立即收齐消息。服务器压力迅速降为0 |
| 发送时间 | 142.8秒 |  |
| 发送速率 | 140条/秒 |  |
| 发送单核速率 | 8.75条/秒 | 发送测试速率除以核心数16 |
| 发送单核分发速率 | 8750条/秒 | 单核测试速度乘于1000 |

### 测试方法及测试视频
测试方法请看[这里](./group_message_test/)。

测试视频：

<a href="https://www.bilibili.com/video/BV1dB4y1H7dn"><img src="./group_message_test/bilibili_video_cover.png" alt="操作视频"></a>

## 聊天室消息测试
聊天室消息测试请看[这里](./chatroom_message_test/)。

## 性能的估算
要想估算好消息的性能，首先需要知道消息都有那些阶段和这些阶段的消耗资源情况，发送一条消息包括：
1. 发送阶段，从收到客户端的请求，到消息落库，到返回给发送者确认这一段的任务。
2. 分发阶段，接着发送阶段处理，读取到分发目标列表，把每个目标的时间线插入这个新的记录并落库。
3. 通知阶段，接着分发阶段，检查目标用户的session，如果在线发送新消息通知给此session对应的客户端。
4. 推送阶段，接着分发阶段，检查目标用户的session，如果不在线检查是否满足推送条件，如果满足推送条件就把推送信息发送推送服务。
5. 拉取阶段，如果客户端收到新消息通知，或者连接成功以后发现有离线消息，就会请求新消息，服务器把新消息读取并返回。

单聊消息的发送测试，测算出来的就是发送阶段的性能数据（也有2次分发，相对于发送可以忽略不计，因此可以简单认为是发送阶段的性能数据），大概是单核心每秒发送1227条

单聊消息的收发测试，是包括发送阶段、通知阶段和拉取阶段的性能数据。已知发送数据和收发数据，可以测算出通知和拉取的性能大概是单核每秒2978条。

实际上很大一部分消息是离线消息拉取。这取决于消息是否在缓存中，如果在缓存中，性能要比通知和拉取要好得多，如果要是不在缓存中，则会读取数据库，性能下降一些。

群组的发送测试就是分发阶段的测试，用千人群的数据来看，单核分发速率是8750条。

剩下的就是通知阶段的性能，这个比较简单只需要一个http请求调用到推送服务，所以性能也不是问题。

媒体类消息对IM服务的压力很小，发送一条媒体类消息需要跟IM服务交互2次（获取上传token和发送消息），上传是直传到对象存储服务，因此主要压力在对象存储服务。

测试的消息内容比较短，如果要是消息内容较大，则性能会有下降，如果大消息比较多，也需要自己做性能测试，测算消息的发送性能。

除了消息的性能，另外一大块就是用户信息和群组信息的更新问题，因为没有想消息这样的通知拉取机制，只能客户端在合适的地方强制刷新用户信息和群组信息。因为有缓存，所以单次的信息拉取消耗极低，***但如果滥用强制刷新，对服务器的压力会很大，而且会引起超频，导致所有功能都不可用，所以一定仅在某些界面强制刷新仅一次，避免多次调用强制刷新***。

上述性能是极限性能，实际线上使用时，要注意保留一定的余地。另外还有相当多的其它操作，虽然比发送消息小，也需要保留一定量的资源。