消息可达性

小苹果IM性能测试及消息可靠性测试报告

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

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

性能及容量总结

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

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

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

可靠性总结

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

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

性能测试

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

测试过程

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

测试条件:日志级别调整为4或更低。

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

测试结论和分析

关注指标 测试结果
同时在线人数 20000个
网关接收消息速度 150条/s
处理写入 300条/s
CPU使用率 约50%
内存使用率 约4G
发送消息响应时长 平均70毫秒
发送过程时延 平约1秒
磁盘空间 5000万条消息占用10G磁盘

资源占用分析

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

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

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

单机性能预估

服务器资源: 8核16G内存, 6个磁盘,每个磁盘100G,100MB带宽。

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

模块 性能情况 说明
msg_gateway 部署多个 ,同时在线5万*2=10万
CPU使用率 约100% 需要优化模块 减少cpu消耗
内存使用率 小于8G 如果内存富余可以增加cache大小
发送消息响应时长 平均70ms
发送过程时延 平约1s 从发送者到接收者
10亿条消息,磁盘空间 占用40*100G磁盘,每个磁盘大概占用70G空间 对于群聊属于扩散写,磁盘消耗较大。整体要考虑磁盘空间富余

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

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

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

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

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

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

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

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

模拟场景&测试方案

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

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

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

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

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

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

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

测试结果

发送消息客户端 接收消息客户端 预设发送消息总量 发送成功条数 发送失败条数 接收消息条数
25个 50个 100000条 99997 3 99997

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

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

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

注意事项:

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

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

成本对比

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