# 再次推荐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

目录
相关文章
|
4天前
|
存储 监控 前端开发
如何确保测试脚本的稳定性和可靠性?
确保测试脚本的稳定性和可靠性是保证性能测试结果准确有效的关键
|
4天前
|
测试技术 数据库连接 数据库
测试脚本的编写和维护对性能测试结果有何影响?
测试脚本的编写和维护对性能测试结果有着至关重要的影响,
7 1
|
22天前
|
编解码 人工智能 自然语言处理
MaskGCT:登上GitHub趋势榜榜首的TTS开源大模型
近日,香港中文大学(深圳)联手趣丸科技推出了新一代大规模声音克隆TTS模型——MaskGCT。一起看看该模型的一些表现吧!
|
2月前
|
监控 中间件 测试技术
『软件测试5』测开岗只要求会黑白盒测试?NO!还要学会性能测试!
该文章指出软件测试工程师不仅需要掌握黑盒和白盒测试,还应该了解性能测试的重要性及其实现方法,包括负载测试、压力测试等多种性能测试类型及其在保证软件质量中的作用。
『软件测试5』测开岗只要求会黑白盒测试?NO!还要学会性能测试!
|
1月前
|
数据采集 应用服务中间件 Go
开源的键鼠共享工具「GitHub 热点速览」
开源的键鼠共享工具「GitHub 热点速览」
|
2月前
|
测试技术 UED 开发者
软件测试的艺术:从代码审查到用户反馈的全景探索在软件开发的宇宙中,测试是那颗确保星系正常运转的暗物质。它或许不总是站在聚光灯下,但无疑是支撑整个系统稳定性与可靠性的基石。《软件测试的艺术:从代码审查到用户反馈的全景探索》一文,旨在揭开软件测试这一神秘面纱,通过深入浅出的方式,引领读者穿梭于测试的各个环节,从细微处着眼,至宏观视角俯瞰,全方位解析如何打造无懈可击的软件产品。
本文以“软件测试的艺术”为核心,创新性地将技术深度与通俗易懂的语言风格相结合,绘制了一幅从代码审查到用户反馈全过程的测试蓝图。不同于常规摘要的枯燥概述,这里更像是一段旅程的预告片,承诺带领读者经历一场从微观世界到宏观视野的探索之旅,揭示每一个测试环节背后的哲学与实践智慧,让即便是非专业人士也能领略到软件测试的魅力所在,并从中获取实用的启示。
|
3月前
|
SQL JavaScript 前端开发
Github 2024-08-05 开源项目周报 Top15
根据 Github Trendings 的统计,本周(2024年8月5日统计)共有15个项目上榜。以下是根据开发语言汇总的项目数量: - Go 项目:4个 - JavaScript 项目:3个 - Python 项目:3个 - Java 项目:2个 - TypeScript 项目:2个 - C 项目:1个 - Shell 项目:1个 - Dockerfile 项目:1个 - 非开发语言项目:1个
113 2
|
3月前
|
人工智能 Rust JavaScript
Github 2024-08-26 开源项目周报Top15
根据Github Trendings的统计,本周共有15个项目上榜。以下是按开发语言汇总的项目数量:Python项目8个,TypeScript、C++ 和 Rust 项目各2个,Jupyter Notebook、Shell、Swift 和 Dart 项目各1个。其中,RustDesk 是一款用 Rust 编写的开源远程桌面软件,可作为 TeamViewer 的替代品;Whisper 是一个通用的语音识别模型,基于大规模音频数据集训练而成;初学者的生成式人工智能(第2版)则是由微软提供的18门课程,教授构建生成式AI应用所需的知识。
126 1
|
3月前
|
Rust Dart 前端开发
Github 2024-08-19 开源项目周报Top15
根据Github Trendings的统计,本周(2024年8月19日统计)共有15个项目上榜。按开发语言分类,上榜项目数量如下:Python项目最多,有7项;其次是JavaScript和TypeScript,各有3项;Dart有2项;HTML、PowerShell、Clojure和C++各1项。此外,还介绍了多个热门项目,包括Bootstrap 5、RustDesk、ComfyUI、易采集、Penpot等,涵盖了Web开发、远程桌面、自动化测试、设计工具等多个领域。
110 1
|
3月前
|
JavaScript 前端开发 Go
Github 2024-08-12 开源项目周报 Top14
本周Github Trendings共有14个项目上榜,按开发语言汇总如下:Python项目7个,TypeScript项目5个,C项目2个,JavaScript项目2个,Go和Batchfile项目各1个。其中亮点包括开发者职业成长指南、Windows激活工具、ComfyUI图形界面、AFFiNE知识库、易采集可视化爬虫等项目,涵盖多种实用工具和开源平台。
125 1