mirror of
https://github.com/WuKongIM/WuKongIMDocs
synced 2025-06-03 07:42:48 +00:00
docs: update
This commit is contained in:
tt
parent
497b55697a
commit
5b7cf7e482
@ -127,7 +127,9 @@ export const sidebar: DefaultTheme.Sidebar = {
|
||||
{ text: "集成到自己系统", link: "/server/advance/integration" },
|
||||
{ text: "WuKongIM 协议", link: "/server/advance/proto" },
|
||||
{ text: "部署压力测试", link: "/server/advance/stress" },
|
||||
// { text: "官方压测报告", link: "/server/advance/stressReport" },
|
||||
{ text: "压测报告（单机）", link: "/server/advance/stressReport" },
|
||||
{ text: "压测报告（分布式）", link: "/server/advance/stressReport" },
|
||||
|
||||
],
|
||||
},
|
||||
],
|
||||
|
||||
@ -23,7 +23,7 @@
|
||||
|
||||
### 2. 日活用户大概40万以下，需要什么部署方案和服务器配置？
|
||||
|
||||
20万以下的日活用户，建议单机部署，单机部署的服务器配置建议：
|
||||
40万以下的日活用户，建议单机部署，单机部署的服务器配置建议：
|
||||
|
||||
- CPU：4核（或2核）
|
||||
- 内存：16G（或8G）
|
||||
|
||||
@ -1,77 +1,207 @@
|
||||
|
||||
# 压力测试报告
|
||||
# 压力测试报告 （分布式）
|
||||
|
||||
## 前序
|
||||
|
||||
一个通讯系统是否优秀，主要看四个指标`稳定性`，`可靠性`，`有序性`，`高性能`
|
||||
|
||||
高性能：极限压测消息发送并发和消息接收并发。
|
||||
|
||||
稳定性：测试在高并发下长时间运行，cpu，内存，带宽是否稳定
|
||||
|
||||
可靠性：测试是否丢消息。
|
||||
|
||||
有序性：测试消息是否乱序。
|
||||
|
||||
|
||||
## 测试目标
|
||||
|
||||
### 稳定性
|
||||
|
||||
目标描述
|
||||
|
||||
## 测试
|
||||
|
||||
所有的压测结果按照压测内容和硬件都能在自己服务器上复现。
|
||||
|
||||
|
||||
### 硬件信息
|
||||
|
||||
| 资源说明 | 硬件 | 数量 |
|
||||
| :-------------- | :----- | :------- |
|
||||
| 三台组成最小WuKongIM分布式单元 | Ubuntu 18.04, 16Core, 32GB RAM, 100GB SSD, 2M EBW(bit/s) | 3台 |
|
||||
| nginx和监控 | Ubuntu 18.04, 16Core, 32GB RAM, 100GB SSD, 2M EBW(bit/s) | 1台 |
|
||||
| 压测机 | Ubuntu 18.04, 16Core, 32GB RAM, 100GB SSD, 2M EBW(bit/s) | 1台 |
|
||||
|
||||
|
||||
### 性能测试
|
||||
|
||||
`通讯系统是否高性能核心指标：发送消息并发数和接收消息并发数（通俗讲：系统一秒钟最大能处理多少消息的发送和投递）`
|
||||
|
||||
|
||||
#### 发送速率测试
|
||||
|
||||
测试内容
|
||||
|
||||
期望结果
|
||||
| 内容 | 在线 | 发送速率 |
|
||||
| :-------------- | :----- | :------- |
|
||||
| 100个100人的群 | 每群1人在线 | 每群一分钟6000条消息
|
||||
|
||||
### 可靠性
|
||||
`总发送速率：100 * (60000/60) = 10000条/秒`
|
||||
|
||||
|
||||
目标描述
|
||||
#### 接收速率测试
|
||||
|
||||
测试内容
|
||||
|
||||
期望结果
|
||||
| 内容 | 在线 | 发送速率 |
|
||||
| :-------------- | :----- | :------- |
|
||||
| 1个10万人群 | 群成员在线数量25000人（25%） | 一分钟60条消息 |
|
||||
|
||||
### 有序性
|
||||
`总接收速率：25000 * (60/60) = 25000条/秒`
|
||||
|
||||
|
||||
目标描述
|
||||
#### 混合测试
|
||||
|
||||
测试内容
|
||||
|
||||
期望结果
|
||||
| 内容 | 在线 | 发送速率 |
|
||||
| :-------------- | :----- | :------- |
|
||||
| 1000对单聊 | 全在线 | 每对一分钟600条消息 |
|
||||
| 1个10万人群 | 群成员在线数量2500人 | 一分钟600条消息 |
|
||||
|
||||
### 并发量
|
||||
`总发送速率：1000 * (600/60) + 10 * (600/60) = 10100条/秒`
|
||||
|
||||
`总接收速率：1000 * (600/60) + 1 * 2500 * (600/60) = 25000条/秒`
|
||||
|
||||
#### 测试结果
|
||||
|
||||
### 稳定性测试
|
||||
|
||||
测试系统是否能在消息低延迟下稳定运行
|
||||
|
||||
#### 测试目标
|
||||
|
||||
测试在发送和接收并发高频的情况下，系统能够平稳运行，消息平均延迟在理想状态（500ms以下）。
|
||||
|
||||
#### 测试内容
|
||||
|
||||
|
||||
目标描述
|
||||
| 内容 | 在线 | 发送速率 |
|
||||
| :-------------- | :----- | :------- |
|
||||
| 1000对单聊 | 1000人在线 | 每对一分钟30条消息 |
|
||||
| 200个200人的群 | 每群50（25%）人在线 | 每群一分钟30条消息 |
|
||||
| 100个500人的群 | 每群125（25%）人在线 | 每群一分钟30条消息 |
|
||||
| 1个1万人群 | 群成员在线数量2500人（25%） | 每群一分钟30条消息 |
|
||||
|
||||
测试内容
|
||||
持续时间：24小时
|
||||
|
||||
期望结果
|
||||
#### 测试结果
|
||||
|
||||
结果截图
|
||||
|
||||
|
||||
核心指标
|
||||
|
||||
| 内容 | 结果 | 说明 |
|
||||
| :-------------- | :----- | :------- |
|
||||
| 同时在线 | | |
|
||||
| 发送条数 | | |
|
||||
| 接收条数 | | |
|
||||
| 成功率 | | |
|
||||
| 发送速率 | | |
|
||||
| 接收速率 | | |
|
||||
| 发送最大延迟 | | |
|
||||
| 发送最小延迟 | | |
|
||||
| 发送平均延迟 | | |
|
||||
| 接收最大延迟 | | |
|
||||
| 接收最小延迟 | | |
|
||||
| 接收平均延迟 | | |
|
||||
|
||||
|
||||
硬件占用
|
||||
|
||||
| 内容 | 节点1 | 节点2 | 节点3 | 说明 |
|
||||
| :-------------- | :----- | :------- | :------- | :------- |
|
||||
| CPU | | | | |
|
||||
| 内存 | | | | |
|
||||
| 带宽 | | | | |
|
||||
|
||||
|
||||
### 可靠性测试
|
||||
|
||||
测试消息是否丢失
|
||||
|
||||
#### 测试目标
|
||||
|
||||
大量收发消息下，所有接收者能全部接收到消息。
|
||||
|
||||
#### 测试内容
|
||||
|
||||
| 内容 | 在线 | 发送速率 |
|
||||
| :-------------- | :----- | :------- |
|
||||
| 1个1万人群 | 群成员在线数量2500人（25%） | 每群一分钟60条消息 |
|
||||
| 100对单聊 | 都在线 | 每对一分钟60条消息 |
|
||||
|
||||
持续时间：1小时
|
||||
|
||||
#### 测试结果
|
||||
|
||||
结果截图
|
||||
|
||||
核心指标
|
||||
|
||||
|
||||
| 内容 | 结果 | 说明 |
|
||||
| :-------------- | :----- | :------- |
|
||||
| 同时在线 | | |
|
||||
| 发送条数 | | |
|
||||
| 接收条数 | | |
|
||||
| 成功率 | | |
|
||||
| 期望接收消息数量 | | |
|
||||
| 实际接收消息数量 | | |
|
||||
|
||||
|
||||
|
||||
## 部署说明
|
||||
### 有序性测试
|
||||
|
||||
3台16核，16G的Ubuntu服务器，分布式部署WuKongIM
|
||||
测试消息是否乱序
|
||||
|
||||
1台8核，16G的Ubuntu服务器，部署负载均衡（nginx）
|
||||
#### 测试目标
|
||||
|
||||
1台8核32G的Ubuntu服务器，部署压测机
|
||||
在一个频道内快速发送消息，看接收者的顺序是否与发送者的一致
|
||||
|
||||
#### 测试内容
|
||||
|
||||
|
||||
## 稳定性测试
|
||||
|
||||
**测试数据：**
|
||||
|
||||
> 5万人在线 + 1000个200人群 + 1000个单聊，每个群内和单聊1秒钟刷一条消息，持续12小时，观察服务是否稳定。
|
||||
|
||||
**测试截图：**
|
||||
|
||||
**测试报告截图：**
|
||||
|
||||
**报告结果分析：**
|
||||
| 内容 | 在线 | 发送速率 |
|
||||
| :-------------- | :----- | :------- |
|
||||
| 1对单聊 | 2人在线 | 一分钟600条消息 |
|
||||
|
||||
|
||||
## 可靠性测试
|
||||
#### 测试结果
|
||||
|
||||
结果截图
|
||||
|
||||
抽样视频
|
||||
|
||||
|
||||
## 有序性测试
|
||||
|
||||
|
||||
## 并发测试
|
||||
|
||||
## 总结
|
||||
|
||||
## 说明
|
||||
|
||||
以上测试，均可自行部署压测机进行验证，文档：[部署压测机](stress.html)
|
||||
以上测试，均可自行部署压测机进行验证，文档：[部署压测机](stress.html)
|
||||
|
||||
## 问题回答
|
||||
|
||||
#### 为什么不做百万长连接在线测试？
|
||||
|
||||
`没必要`，`无意义`。
|
||||
|
||||
没必要：现在的硬件百万长连接同时在线并没什么难度，Go程序无需做过多优化都能实现
|
||||
|
||||
无意义：如果只是百万长连接同时在线不收发消息毫无意义，因为IM核心指标是`发送消息并发数和接收消息并发数（通俗讲：系统一秒钟最大能处理多少消息的发送和投递）`。
|
||||
|
||||
测试的核心还是要围绕：消息延迟大小（稳定性），是否丢消息（可靠性），消息是否乱序（有序性），消息并发数（高性能）来进行全方面测试
|
||||
|
||||
|
||||
#### 分布式为什么比单机性能低？
|
||||
|
||||
分布式版本因为需要节点之间消息同步，所以会有格外的一致性通讯和存储的格外消耗。
|
||||
|
||||
但是分布式可以通过增加节点来提升整个系统的性能，理论上只要节点够，性能无上限。
|
||||
Loading…
x
Reference in New Issue
Block a user