共计 3395 个字符，预计需要花费 9 分钟才能阅读完成。
压测前筹备（一）服务端配置调整 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/#
