乐趣区

关于架构设计:靠谱开源IM项目OpenIM压测程序介绍自己动手压测性能和稳定性

压测前筹备(一)服务端配置调整 config/config.yaml 以 8 核 16G 为例
(1)openImMessagePort: [10130, 10131, 10132, 10133, 10134,10135]
(2)openImPushPort: [10170, 10171, 10172, 10173]
(3)remainLogLevel: 3
(4)chatpersistencemysql: false
(5) dbMaxOpenConns: 100

 dbMaxIdleConns: 10
 dbMaxLifeTime: 5


(二)调整 path_info.cfg 中 msg_transfer_service_num=4

(三)kafka 分区调整
(1)设置 ws2ms_chat 为 8 个分区 msg_transfer_service_num 的 2 倍
(2)设置 msg_to_mongo 为 8 个分区 msg_transfer_service_num 的 2 倍
(3)设置 ms2ps_chat 为 8 个分区 openImMessagePort 的 2 倍

(四)mysql 服务端设置最大连接数为 2000

注意事项(1)因为须要本地解决 sqlite 读写,检测程序倡议设置 2 个客户端,发送音讯休眠 100 毫秒;
(2)留神压测客户端和服务端的网络带宽;
(3)如果客户端和服务端同一台机器,留神压测程序 cpu 占用;单聊压测程序仓库地址
https://github.com/OpenIMSDK/…
代码阐明
press_open_im.go 压测音讯发送,但发送者不校验是否实现接管到
msg_delay_open_im.go 检测音讯发送和接管,在大压力状况下,音讯的可靠性和时延测试
应用阐明
(1)批改../test/config.go TESTIP 和 SECRET
(2)go build press_open_im.go
./press_open_im -sn 10000 -mn 1000 -t 100
参数 sn 10000 示意:启动 10000 个压测客户端;
参数 mn 1000 示意:每个客户端发送音讯数量为 1000 条;
参数 t 100 示意:每次发送一条音讯后,休眠 100 毫秒;如果是 1 万客户端,算起来大略是每秒钟发送 10 万条音讯;
(3)go build msg_delay_open_im.go
./msg_delay_open_im -sn 2 -mn 1000 -t 100
参数 sn 2 示意:启动 2 个客户端音讯收发检测;
参数 mn 1000 示意:每个客户端发送 1000 条音讯;
参数 t 100 示意:每次发送一条音讯,休眠 100 毫秒;

压测程序应用示例./press_open_im -sn 100 -mn 100000 -t 100
呈现 [send msg begin] 示意初始化实现,开始发送音讯
此时再启动可靠性及音讯时延测试:
./msg_delay_open_im -sn 2 -mn 1000 -t 100 服务端统计日志查看 tail -f OpenIM.log.all.2022-08-30 |grep “msg_gateway sendMsgCount”
system stat msg_gateway 60 second recv to msg_gateway sendMsgCount 45267
示意一分钟收到 45267 条音讯时延检测查看 minCostTime: 729 ms, maxCostTime: 6332 ms, average cost time: 3295 ms 发送 2000 条数据 从发送到对方收到,均匀时延是 3.2 秒
CheckReliabilityResult ok, exit 示意收回去的所有音讯,对方都能准确收到群聊压测程序仓库地址
https://github.com/OpenIMSDK/…
代码阐明
create_work_group_open_im.go 创立测试群
press_open_im.go 压测音讯发送,但发送者不校验是否实现接管到
msg_delay_open_im.go 检测音讯发送和接管,在大压力状况下,音讯的可靠性和时延测试
应用阐明
(1)批改../test/config.go TESTIP 和 SECRET
(2)go build create_work_group_open_im.go
./create_work_group_open_im -gmn 10
参数 gmn 示意:创立群成员为 10 的测试群,理论会创立 13 个成员。
(3)go build press_open_im.go
./press_open_im -gid 1510503557 -sn 10 -mn 1000 -t 100
参数 gid 1510503557 示意:压测群聊 groupID
参数 sn 10 示意:压测客户端数量,要小于等于群成员数
参数 mn 1000 示意:每个客户端发送音讯数量为 1000 条;
参数 t 100 示意:每次发送一条音讯,休眠 100 毫秒;
(4)go build msg_delay_open_im.go

./msg_delay_open_im -gid 1510503557 -mn 100 -t 100

参数 gid 1510503557 示意:压测群聊 groupID
参数 mn 100 示意:每个客户端发送音讯数量为 100 条;
参数 t 100 示意每次发送一条音讯,休眠 100 毫秒;

压测程序应用示例./create_work_group_open_im -gmn 10
呈现 [[CREATE GROUP {“errCode”:0,”errMsg”:””,”data”:{“creatorUserID”:”openIM123456″,”groupID”:”3144245614″,”groupName”:”Group Chat”,”groupType”:2,”memberCount”:13,”ownerUserID”:”openIM123456″}} ] 示意创立群聊胜利,记录 groupID 3144245614

启动压测程序:
./press_open_im -gid 3144245614 -sn 10 -mn 1000 -t 100
此时再启动可靠性及音讯时延测试:
./msg_delay_open_im -gid 3144245614 -mn 100 -t 100 服务端统计日志查看 tail -f OpenIM.log.all.2022-08-30 |grep “msg_gateway sendMsgCount”
system stat msg_gateway 60 second recv to msg_gateway sendMsgCount 45267
示意一分钟收到 45267 条音讯时延检测查看 minCostTime: 594 ms, maxCostTime: 5181 ms, average cost time: 2930 ms 发送 2000 条数据 从发送群聊到对方收到,均匀时延是 3.2 秒
CheckReliabilityResult ok, exit 示意收回去的所有群聊音讯,对方都能准确收到。对于 OpenIMOpenIM 是由 IM 技术专家打造开源即时通讯组件,也是目前最受欢迎的开源 IM 我的项目之一,开发者通过集成 OpenIM 组件,并私有化部署服务端,能够将即时通讯、实时通信能力疾速集成到本身利用中,并确保业务数据的安全性和私密性。github 社区沉闷,star 近万,排名遥遥领先,开发者万人,OpenM 力争开源 IM 我的项目 No1,打造开源 IM 第一社区。反对 Android、iOS 原生开发,反对 Flutter、uni-app 跨端开发,反对小程序、React 等所有支流 web 前端技术框架,PC 反对 Electron。重点利用在政务办公,社交,web3 场景,所有皆可控,让 OpenIM 深刻到各行业。从开源的外在含意来看,须要这五个维度:透明度;合作;继续公布;精英制度;社区经营,OpenIM 在这五方面还须要继续致力,巩固生态建设,坚固 OpenIM 影响力。

作为开源 IM 领跑者,OpenIM 开源有几个目标:(1)IM 外围数据应该掌控在运营者手中(2)IM 需要宽泛,有很多人收费应用,并能发现问题(3)让更多开发者参加我的项目我的项目,特地是 IM 需要繁多。在开源社区外面,每个我的项目都能够开启 pr,pr 性能将容许每一位开发者对代码进行批改,然而须要我的项目拥有者的合并代码。个体的力量是最大的,充分体现开源的价值。github 地址:https://github.com/OpenIMSDK/… 开发者核心:https://doc.rentsoft.cn/#

退出移动版