# 再次推荐github 6.7k star开源IM项目OpenIM性能测试及消息可靠性测试报告

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
性能测试 PTS,5000VUM额度
简介: 本报告主要分为两部分,性能测试和消息可靠性测试。前者主要关注吞吐,延时,同时在线用户等,即通常所说的性能指标。后者主要模拟真实环境(比如离线,在线,弱网)消息通道的可靠性。

本报告主要分为两部分,性能测试和消息可靠性测试。前者主要关注吞吐,延时,同时在线用户等,即通常所说的性能指标。后者主要模拟真实环境(比如离线,在线,弱网)消息通道的可靠性。

先说结论,对于容量和性能:

性能及容量总结

服务器资源: 8核16G内存, 6个机械磁盘,每个磁盘100G, 用于mongo分片,10MB带宽。

容量:用户容量10万以上,消息条数10亿条。

性能评估:同时在线用户10万,每秒钟发送消息900条,消息延时1秒(从发送者发出消息到接收到消息)

可靠性总结

启动sdk,模拟50个用户在线、离线情况,消息可靠性100%。

发送10万消息,有3条失败,其他消息都能被对方精确收到,并成功落地本地db。对于失败的3条消息,接收方确实没有收到,系统消息是一致的。

项目介绍

OpenIM是由前微信技术专家打造的开源的即时通讯组件。Open-IM包括IM服务端和客户端SDK,是一套整体的解决方案,代码开源,一切可控,

github地址:https://github.com/OpenIMSDK/Open-IM-Server

开发者中心: https://doc.rentsoft.cn/#/
开发者中心.png
磁盘.png

在单机的情况下,模拟线上用户发消息流程,在线用户量和消息量达到一定量级后,系统CPU、内存、磁盘占用、以及消息时延情况。以确定用户群体达到一定量级后,对服务器资源的预先评估。本次测试并不极限测试,一是因为生产环境本来都会有用户量和消息量的限制,二是因为OpenIM的消息模型,消息发送首先都会通过websocket入库kafka,理论上发送消息的写入性能是两者的组合,而消息发送的真正瓶颈实际在mongodb的随机读写。

测试过程

服务器资源: 腾讯云主机(香港)1台:linux Ubuntu 18.04.4系统,4核8G内存,单块机械硬盘。5Mb带宽。

测试条件:去掉消息入库mysql(因mysql仅用于管理后台,不影响线上用户服务)。日志级别调整为4或更低。kafka设置2个分区,msg_transfer 2个。

测试流程:1个客户端(成都,window pc,4核16G内存)启动1万个协程,模拟用户与服务器建立websocket长连接,间隔时间为随机50-100秒之间。两个客户端共模拟2万用户同时在线,发送消息,观察消息流转各个模块的处理能力,共计2500万条消息,观察系统内存、磁盘资源使用情况。

测试结论和分析

| 关注指标 | 测试结果 |

| 同时在线人数 | 20000个 |

| 网关接收消息速度 | 150条/s(因为瓶颈不在此,故意控制发送速度,以确保kafka能被快速消费入mongodb) |

| mongodb处理写入 | 300条/s (收件箱模型,导致消息一拆为二) |

| CPU使用率 | 约50% |

| 内存使用率 | 约4G(mongo内存限制2G,由于每个文档存储5k条消息,实际实际索引量很小。 redis只存了用户seq映射关系,基本不占内存) |

| 发送消息响应时长 | 平均70毫秒 |

| 发送过程时延 | 平约1秒 |

| 磁盘空间 | mongo中5000万条消息占用10G磁盘,由于一拆为二的缘故,mongo的50000万条消息,实际为2500万条消息。<br/> |

mongodb数据情况

mongodb.png

redis数据情况
redis.png

磁盘状态

资源占用分析

(1)redis内存消耗极小,一个用户一条数据(包括token和seq),和用户量成正比,3万用户占用几十M内存。

(2)mongodb如果去掉cache,内存消耗极小,每个document存放5000条消息,与用户量和消息量成正比,3万用户,2500万消息,索引才950K(更好的方式查看mongo消耗cache之外的内存)

(3)2500万消息,磁盘空间占用10G。

(4)每秒钟150条消息,cpu整体占用50%,即2核。

性能分析

(1)性能瓶颈在mongodb写入操作,1条消息,需要按照发送者和接收者拆分2次,mongodb写入2次,未来可以针对mongodb读写进一步优化。

(2)对于cpu消耗较大的模块,未来做一次整体优化。

(3)性能很平稳,不会随着数据量增加而降低。机械磁盘iops 达到200基本达到了设备的极限

单机性能预估

服务器资源: 8核16G内存, 6个磁盘,每个磁盘100G, 用于mongo分片,10MB带宽。

性能评估:同时在线用户10万,每秒钟发送消息900条,消息延时1秒(从发送者发出消息到接收到消息)

| 模块 | 性能情况 | 说明 |

| msg_gateway | 部署多个 | ,同时在线5万*2=10万 |

| mongodb | 6分片,每个磁盘对应一个分片 | 1800条/每秒消息入库 |

| CPU使用率 | 约100% | 需要优化模块 减少cpu消耗 |

| 内存使用率 | 小于8G(mongo内存限制2G) | 如果内存富余可以增加mongodb的cache大小 |

| 发送消息响应时长 | 平均70ms | |

| 发送过程时延 | 平约1s | 从发送者到接收者 |

| 10亿条消息,磁盘空间 | 占用40*100G磁盘,每个磁盘大概占用70G空间 | 对于群聊属于扩散写,磁盘消耗较大。整体要考虑磁盘空间富余 |

未来工作优化

(1)mongo集群部署,支持上亿用户同时在线,千亿级消息;

(2)简化集群部署;

(3)数据备份、恢复工具;

以上主要对服务端性能做了一个大致测试,但一套完整的IM解决方案,不仅仅是服务端的工作。实际上,客户端重要性毋庸置疑,具体包括如何利用seq和服务端同步消息,如果保证消息收发的时序,如何回调客户端(会话改变、新增,新消息),消息落地本地db,seq同步,消息推拉如何结合以确保消息收发可靠性。

消息可达率(可靠性)测试

相比于性能测试,实际上,消息的可达性(可靠性)更为重要。所以,我们在做性能测试的同时,也要对消息的可达性(可靠性)进行测试,如果不能保证消息收发的正确性,再高的性能也是徒劳。本文重点总结关于OpenIM对于消息可达性测试的方案、过程以及结果。先说结论,OpenIM消息可达率100%,大家可以放心使用在生产环境中。seq对齐和同步机制,保证了OpenIM的消息可达性是业界领先的。

消息可达性(可靠性)的定义

IM消息系统的可靠性,通常就是指消息投递的可靠性,即我们经常听到的“消息必达”,通常用消息的不丢失和不重复两个技术指标来表示。确保消息被发送后,能被接收者收到。由于网络环境的复杂性,以及用户在线的不确定性,消息的可靠性(不丢失、不重复)无疑是IM系统的核心指标,也是IM系统实现中的难点之一。总体来说,IM系统的消息“可靠性”,通常就是指聊天消息投递的可靠性(准确的说,这个“消息”是广义的,因为还存用户看不见的各种指令和通知,包括但不限于进群退群通知、好友添加通知等,为了方便描述,统称“消息”)。

从消息发送者和接收者用户行为来讲,消息“可靠性”应该分为以下几种情况:

(1)发送失败,对于这种情况IM系统必须要感知到,明确反馈发送方。如果此消息没有发送成功,发送方可以选择重试或者稍后再试。

(2)发送成功,如果接收方处在“在线”状态,应该立即收到此消息。如果接收方处在“离线”状态不能收到消息,一旦上线则立刻收到消息。

(3)消息不能重复,用数学术语表示:“有且仅有这条消息”,如果重复了,可能表达的意思就变了。 总之,一个商用 IM系统,必须包含消息“可靠性”逻辑,才能谈基本可用,这是IM系统最基本也是最核心的逻辑。

模拟场景&测试方案

互联网真实场景复杂,但客户端大体可以分为两种情况:(1)发送消息时,接收方在线,能收到消息;(2)发送消息时接收方不在线,登录后能收到离线消息。我们用测试程序模拟互联网客户端各种场景,按照登录、发送消息、接收消息的情况,把测试客户端分为以下2种类型:

(1)启动测试时离线,随机sleep 0-60 秒后登录,发送消息,且接收消息

(2)启动测试时离线,随机sleep 0-60 秒后登录,不发送消息,只接收消息


test.ReliabilityTest(oneClientSendMsgNum, intervalSleepMs, imIP, randSleepMaxSecond, testClientNum)

在实际测试中共计50个客户端,约25个(50%概率)客户端不发送只接收消息,约25个(50%概率)客户端发送且接收消息 。

发送模式:每个客户端随机选择其他客户端作为消息接收者;

测试预期: 每一条发送成功的MsgID,都能在接收的消息列表中找到,同样,每一条接收到的MsgID,都能在发送成功的消息列表中找到。

具体做法:(1)消息发送成功后,通过OnSuccess回调,记录MsgID; 收到新消息后回调OnRecvNewMessage,记录MsgID;(2)周期性对比两个消息列表,确认是否完全一致;

测试结果

| 发送消息客户端 | 接收消息客户端 | 预设发送消息总量 | 发送成功条数 | 发送失败条数 | 接收消息条数 | |

| 25个 | 50个 | 100000条 | 99997 | 3 | 99997 | |

发送数据100000条,其中失败3条,9999997条成功,接收方成功接收9999997条消息(接收方成功接收到消息,写入本地db,并能触发消息回调)

每一条发送成功的消息,对方都能准确接收到,无论接收方在消息发送时的登录状态是在线还是离线。

每一条发送失败的消息,对方都不会收到。

测试程序


main/main.go

intervalSleepMs := 1

randSleepMaxSecond := 30

imIP := "127.0.0.1"  //OpenIM ip

oneClientSendMsgNum := 4000 //每个客户端发送的消息条数

testClientNum := 50  //同时启动压测客户端数量

func main() {

reliabilityTest()

}

注意事项:

(1)控制压力,因为sdk需要写本地db,客户端会成为压力瓶颈。

(2)压测客户端日志会影响测试性能。

成本对比

此表格是某IM云平台的价格,如果按照10万月活,存储三年消息来算,大概每年需要支付15万。而采用OpenIM只需要采购云主机,每年成本约0.8万。
云1.png
云2.png

目录
相关文章
|
29天前
|
存储 网络协议 前端开发
基于开源IM即时通讯框架MobileIMSDK:RainbowChat v11.7版已发布
Android端主要更新内容: 1)[优化] 优化了首页“消息”列表中单聊类型未正确同步时的收发消息和点击后的处理逻辑; 2)[优化] 优化了首页“消息”列表中同一好友和陌生人会话不能自动合并的问题;
49 2
|
2天前
|
网络协议 关系型数据库 应用服务中间件
【项目场景】请求数据时测试环境比生产环境多花了1秒是怎么回事?
这是一位粉丝(谢同学)给V哥的留言,描述了他在优化系统查询时遇到的问题:测试环境优化达标,但生产环境响应时间多出1秒。通过抓包分析,发现MySQL请求和响应之间存在500毫秒的延迟,怀疑是网络传输开销。V哥给出了以下优化建议:
|
27天前
|
测试技术
自动化测试项目学习笔记(五):Pytest结合allure生成测试报告以及重构项目
本文介绍了如何使用Pytest和Allure生成自动化测试报告。通过安装allure-pytest和配置环境,可以生成包含用例描述、步骤、等级等详细信息的美观报告。文章还提供了代码示例和运行指南,以及重构项目时的注意事项。
124 1
自动化测试项目学习笔记(五):Pytest结合allure生成测试报告以及重构项目
|
11天前
|
编解码 人工智能 自然语言处理
迈向多语言医疗大模型:大规模预训练语料、开源模型与全面基准测试
【10月更文挑战第23天】Oryx 是一种新型多模态架构,能够灵活处理各种分辨率的图像和视频数据,无需标准化。其核心创新包括任意分辨率编码和动态压缩器模块,适用于从微小图标到长时间视频的多种应用场景。Oryx 在长上下文检索和空间感知数据方面表现出色,并且已开源,为多模态研究提供了强大工具。然而,选择合适的分辨率和压缩率仍需谨慎,以平衡处理效率和识别精度。论文地址:https://www.nature.com/articles/s41467-024-52417-z
32 2
|
15天前
|
移动开发 网络协议 小程序
基于开源IM即时通讯框架MobileIMSDK:RainbowChat-iOS端v9.1版已发布
RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题
46 5
|
27天前
|
测试技术 Python
自动化测试项目学习笔记(四):Pytest介绍和使用
本文是关于自动化测试框架Pytest的介绍和使用。Pytest是一个功能丰富的Python测试工具,支持参数化、多种测试类型,并拥有众多第三方插件。文章讲解了Pytest的编写规则、命令行参数、执行测试、参数化处理以及如何使用fixture实现测试用例间的调用。此外,还提供了pytest.ini配置文件示例。
19 2
|
6天前
|
NoSQL 测试技术 Go
自动化测试在 Go 开源库中的应用与实践
本文介绍了 Go 语言的自动化测试及其在 `go mongox` 库中的实践。Go 语言通过 `testing` 库和 `go test` 命令提供了简洁高效的测试框架,支持单元测试、集成测试和基准测试。`go mongox` 库通过单元测试和集成测试确保与 MongoDB 交互的正确性和稳定性,使用 Docker Compose 快速搭建测试环境。文章还探讨了表驱动测试、覆盖率检查和 Mock 工具的使用,强调了自动化测试在开源库中的重要性。
|
27天前
|
测试技术 Python
自动化测试项目学习笔记(二):学习各种setup、tearDown、断言方法
本文主要介绍了自动化测试中setup、teardown、断言方法的使用,以及unittest框架中setUp、tearDown、setUpClass和tearDownClass的区别和应用。
49 0
自动化测试项目学习笔记(二):学习各种setup、tearDown、断言方法
|
1月前
|
人工智能 自动驾驶 机器人
【通义】AI视界|苹果自动驾驶汽车项目画上句号:加州测试许可被取消
本文精选了24小时内的重要科技新闻,包括Waymo前CEO批评马斯克对自动驾驶的态度、AMD发布新款AI芯片但股价波动、苹果造车项目终止、Familia.AI推出家庭应用以及AI逆向绘画技术的进展。更多内容请访问通义官网体验。
|
1月前
|
前端开发 JavaScript 应用服务中间件
linux安装nginx和前端部署vue项目(实际测试react项目也可以)
本文是一篇详细的教程,介绍了如何在Linux系统上安装和配置nginx,以及如何将打包好的前端项目(如Vue或React)上传和部署到服务器上,包括了常见的错误处理方法。
170 0
linux安装nginx和前端部署vue项目(实际测试react项目也可以)

热门文章

最新文章