野火专业版IM服务性能测试报告

野火专业版IM服务拥有非常强大的性能表现，在即时通讯行业内的性能指标是遥遥领先的，所有的测试方法和测试过程全都公开，专业版客户可以自己来测试性能表现。

测试分为长连接测试、单聊消息发送测试、群聊消息发送测试和聊天室发送消息测试。测试结果分别如下：

1. 单机百万长连接测试

测试方法：单台IM服务，模拟一百万用户连接上并保持在线不掉线30分钟以上。

硬件需求：一台16核32G腾讯云标准S6云服务器，一台4C8G腾讯云MySQL服务器。

测试结果：成功保持30分钟以上，无掉线。保持期间IM服务CPU利用率十核左右，MySQL 利用率为0。

测试详情：https://gitee.com/wfchat/C1000K_Test

测试视频：https://www.bilibili.com/video/BV1TZ4y1e7Ct

2. 单聊消息测试

单聊消息测试分2部分：第一个测试是发送测试，只发送消息，接收对象离线；第二个测试是收发测试，发送消息同时，接收对象在线实时接收消息。测试是使用腾讯云云服务进行的，一台8核32G腾讯云标准S6云服务器，一台8C16G腾讯云MySQL服务器。合计16核48G服务器资源。

2.1. 发送消息测试

测试方法：200个发送用户，1000个接收用户，其中999个接收用户离线，有1个接收用户为真实手机客户端在线，实时接收消息。测试一次发送50轮，发送消息总量为一千万条。

测试结果：

2.2. 收发消息测试

测试方法：200个发送用户，1000个接收用户，接收用户全部在线实时接收消息，其中有1个接收用户为真实手机客户端，实时接收消息。测试一次发送50轮，发送消息总量为一千万条。

测试结果：

2.3. 测试方法和测试视频

发送消息测试和收发消息测试，可以在下面测试详情找到说明，可以在测试视频中观看我们测试过程。可以根据测试详情和视频来自己验证野火专业版IM服务的性能。

测试详情：https://gitee.com/wfchat/Performance_Test/tree/main/single_message_test

测试视频：https://www.bilibili.com/video/bv1EY4y1n7iS

3. 群聊消息测试

群聊测试分表测试了百人群、两百人群和千人群。使用腾讯云北京6区一台标准S6云服务器8C32G和一台云MySQL服务8C16G，测试结果如下：

3.1. 百人群发送消息测试：

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

3.2. 两百人群发送消息测试：

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

3.3. 千人群发送消息测试：

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

3.4. 测试方法及测试视频

发送消息测试和收发消息测试，可以在下面测试详情找到说明，可以在测试视频中观看我们测试过程。可以根据测试详情和视频来自己验证野火专业版IM服务的性能。

测试详情：https://gitee.com/wfchat/Performance_Test/tree/main/group_message_test

测试视频：https://www.bilibili.com/video/BV1dB4y1H7dn

4. 聊天室消息测试

使用腾讯云北京标准S6 8核16G云服务器测试结果如下：

4.1. 测试千人聊天室

4.2. 测试两千人聊天室

4.3. 测试五千人聊天室

4.4. 结果分析

从结果看出，当聊天室人数增大，性能下降很多。原因是当聊天室人数增大时，聊天室内发送消息的速率会降低，单位时间内发送的消息数降低，每个用户单位时间内的消息就减少，这样丢消息的比例就降低了。实际上在到达5000人时，消息基本上不丢了。后面基本上稳定在单核13000条/秒广播拉取速率左右。

4.5. 测试方法及测试视频

测试详情：https://gitee.com/wfchat/Performance_Test/tree/main/chatroom_message_test

测试视频：https://www.bilibili.com/video/BV1VW4y117p9

5. 性能的估算

要想估算好消息的性能，首先需要知道消息都有那些阶段和这些阶段的消耗资源情况，发送一条消息包括：

1. 发送阶段，从收到客户端的请求，到消息落库，到返回给发送者确认这一段的任务。
2. 分发阶段，接着发送阶段处理，读取到分发目标列表，把每个目标的时间线插入这个新的记录并落库。
3. 通知阶段，接着分发阶段，检查目标用户的session，如果在线发送新消息通知给此session对应的客户端。
4. 推送阶段，接着分发阶段，检查目标用户的session，如果不在线检查是否满足推送条件，如果满足推送条件就把推送信息发送推送服务。
5. 拉取阶段，如果客户端收到新消息通知，或者连接成功以后发现有离线消息，就会请求新消息，服务器把新消息读取并返回。

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

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

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

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

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

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

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

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

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