性能测试报告
ThingsPanel在Raspberry Pi上的全面性能分析报告
测试结论
ThingsPanel能够在2GB内存的树莓派上稳定运行，适合中小规模IoT应用场景。测试表明系统能够处理每秒约700个数据点的持续写入，足以稳定支持5个设备的100毫秒数据上报，或者20000个温湿度传感器1分钟频率数据上报。主要性能瓶颈是存储I/O性能而非CPU或内存，特别是在使用标准Class 10 TF卡时。通过优化存储介质（如使用A2级SD卡或外接SSD），系统性能还有10-30倍提升空间。整体而言，树莓派是部署ThingsPanel的经济有效选择，为边缘计算IoT应用提供了可行方案。
测试方法
本测试采用了多维度资源监控与实际负载测试相结合的方法，全面评估ThingsPanel在树莓派上的性能表现：
-
系统资源监控：
- 使用自定义脚本
monitor_thingspanel.sh实时监控CPU、内存和各组件资源使用 - 使用
pg_io_monitor.sh专门监控磁盘I/O性能，重点关注数据库分区 - 采样间隔1秒，记录各组件资源占用情况
- 使用自定义脚本
-
负载测试：
- 模拟10个IoT设备并发连接，使用MQTT协议向系统发送数据
- 测试数据发送速率约989点/秒，持续200个循环
- 通过数据库查询验证数据写入成功率和性能
-
性能分析：
- 对比空闲状态和负载状态下的资源使用差异
- 识别系统瓶颈点及其影响程度
- 分析各组件（PostgreSQL、Redis、GMQTT等）的资源占用特征
测试环境
-
硬件平台：
- Raspberry Pi 4
- CPU: 4核心ARM处理器 (aarch64架构)
- 内存: 1849MB (约2GB)
- 存储: Class 10 TF卡，根分区使用率约94%
-
软件环境：
- 操作系统: Raspbian GNU/Linux 11 (bullseye)
- ThingsPanel组件版本:
- PostgreSQL/TimescaleDB (Docker容器)
- Redis (Docker容器)
- GMQTT (PM2管理)
- Backend API (PM2管理)
- Nginx (系统服务)
-
测试工具：
- 自定义资源监控脚本
- MQTT性能测试客户端 (Go语言实现)
- 数据库监控查询脚本
资源使用总结
空闲状态 (无数据写入时)
| 指标 | 使用率 | 实际使用量 |
|---|---|---|
| 总CPU使用率 | 4.2% - 7.4% | 单核最高约7.4% |
| 总内存使用率 | 约35.2% | 约651MB |
| 磁盘写入 | 0 - 0.07MB/秒 | 几乎无写入 |
| ThingsPanel总CPU | 约2.2% | 单核约2.2% |
| ThingsPanel总内存 | 约21.2% | 约436MB |
负载状态 (有大量数据写入时)
| 指标 | 使用率 | 实际使用量 |
|---|---|---|
| 总CPU使用率 | 92.3% - 94.1% | 单核满负载 |
| 总内存使用率 | 36.4% - 36.9% | 约682MB |
| 磁盘写入(mmcblk0p2) | 2.3 - 7.1MB/秒 | 峰值达7.1MB/秒 |
| ThingsPanel总CPU | 82.3% - 113.2% | 超过单核100% |
| ThingsPanel总内存 | 28.0% - 30.9% | 566MB - 621MB |
各组件资源占用分析
PostgreSQL数据库
- 空闲时 - CPU: ~0%, 内存: 13.2% (267.3MB), 磁盘写入: 几乎为0
- 负载时 - CPU: 80.1% - 111.0%, 内存: 19.9% - 22.8% (396MB - 451MB), 磁盘写入: 2.3 - 7.1MB/秒
- 特点:
- 是CPU、内存和磁盘I/O的主要消耗源
- 负载时CPU利用率可达单核满载以上
- 数据写入会产生大量磁盘I/O，是系统性能瓶颈
Redis
- 空闲/负载时 - CPU: 稳定在约1.6%, 内存: 0.4% (18.7MB), 磁盘I/O影响极小
- 特点: 资源占用稳定，不因负载增加而显著变化
GMQTT (MQTT服务器)
- 空闲/负载时 - CPU: ~0%, 内存: 0.1% (2.5MB), 磁盘I/O几乎无影响
- 特点: 资源占用极低，即使在MQTT消息频繁传输时也保持稳定
Backend (后端API服务)
- 空闲/负载时 - CPU: ~0%, 内存: 0.1% (2.7MB), 磁盘I/O影响极小
- 特点: 资源占用极低，处理能力良好，主要工作是数据传递
Nginx (Web服务器)
- 空闲/负载时 - CPU: ~0%, 内存: 0.9% (19.0MB), 磁盘I/O几乎无影响
- 特点: 资源占用稳定，轻量级
NodeJS/PM2 (进程管理)
- 空闲/负载时 - CPU: 约0.6%, 内存: 6.5% - 6.6% (126MB - 127MB), 磁盘I/O几乎无影响
- 特点: 内存占用中等，CPU占用低
磁盘I/O性能分析
从磁盘I/O监控数据可以看出以下几点重要信息：
-
I/O负载与CPU负载强相关:
- 在CPU使用率高峰期(90%+)，分区写入速度稳定在2.3-3.0MB/秒
- 在某些峰值时刻，写入速度可达7.1MB/秒
-
存储性能表现:
- Class 10 TF卡的随机写入性能为系统瓶颈之一
- 写入速度在峰值负载下达到了7.1MB/秒，接近Class 10卡随机写入的性能上限
- 根分区(mmcblk0p2)使用率已达94%，这可能对写入性能有负面影响
-
特定设备与分区I/O差异:
- 整个设备(mmcblk0)的I/O监控数据与分区(mmcblk0p2)数据存在差异
- 必须监控具体分区而非整个设备，才能准确捕获数据库的I/O活动
-
数据库I/O特性:
- PostgreSQL写入模式呈现为突发性，写入速率在负载期间相对稳定
- 写入操作几乎完全由PostgreSQL数据库生成，其他组件几乎不产生磁盘写入
负载测试分析
根据测试日志中的数据，系统在执行性能测试时表现如下：
-
数据写入能力:
- 系统能够处理约989点/秒的数据写入速率
- 平均数据库写入率达到70.7% - 96.3%
- 在测试高峰期能够处理约710点/秒的数据库写入速率
-
系统响应:
- 面对高频率数据写入，CPU使用率迅速上升至90%以上
- PostgreSQL数据库成为主要的资源消耗点(CPU和磁盘I/O)
- 内存使用率保持相对稳定，仅增加约1.7%
- 磁盘写入在数据库活动期间显著增加，与CPU使用率高度相关
-
资源恢复:
- 当数据写入减少时，系统资源使用快速下降
- CPU使用率从92.3%降至25%
- PostgreSQL的CPU使用率从80.1%降至22.6%
- 磁盘写入速率迅速下降，趋近于零
关键性能瓶颈识别
基于CPU、内存和磁盘I/O的综合监控数据，可以明确识别ThingsPanel在树莓派上的主要性能瓶颈：
-
主要瓶颈 - 存储I/O性能:
- Class 10 TF卡的随机写入速度在处理数据库写入时接近极限
- 实测峰值写入速度达7.1MB/秒，接近理论上限
- 主要影响系统在高数据吞吐量情况下的稳定性
-
次要瓶颈 - CPU处理能力:
- PostgreSQL在高负载下CPU使用率超过100%，即超过单核心处理能力
- 数据库写入和查询处理是CPU密集型工作
- 多核心的利用有助于提升整体性能
-
非瓶颈 - 内存容量:
- 即使在负载下，系统内存使用率仅增加约1.7%
- 2GB内存对ThingsPanel来说有足够余量
- 内存不是当前配置下的限制因素
结论与建议
总体评估
ThingsPanel在Raspberry Pi (2GB)上表现良好，能够满足中小规模IoT应用需求:
- 可行性: 即使在2GB RAM的Raspberry Pi上，ThingsPanel也能稳定运行
- 性能: 可持续处理约600-700点/秒的数据写入，足够支持10设备同时高频率数据上报
- 资源使用效率: 空闲时仅占用约21.2%的系统内存和极少的CPU
- 扩展性: 系统在负载下保持稳定，内存使用率增加有限
优化建议
存储优化 (首要优先级):
- 使用高性能SD卡(A2级别)或外接SSD通过USB 3.0接口
- 清理根分区，保持至少15-20%的可用空间
- 考虑将PostgreSQL数据目录移至单独的高速存储设备
SD卡与SSD在ThingsPanel上的性能对比
| 性能指标 | Class 10 SD卡 | SSD (USB 3.0) | 提升倍数 |
|---|---|---|---|
| 随机写入速度 | 2-7 MB/秒 | 80-300 MB/秒 | 10-30倍 |
| 数据点处理能力 | ~700点/秒 | 3,500-10,000点/秒 | 5-15倍 |
| 数据库查询响应 | 较慢 | 显著更快 | 5-15倍 |
| 高负载时CPU使用率 | 90-110% | 30-50% | CPU减负60-70% |
| 系统稳定性 | 容易成为瓶颈 | 大幅提升 | 质的改善 |
总结
ThingsPanel在ARM设备尤其是Raspberry Pi上是完全可行的，能够有效支持中小规模IoT应用场景。主要性能瓶颈在于存储I/O性能和数据库处理能力，而非内存限制。即使在2GB内存的设备上，ThingsPanel仍能保持较好的性能表现，这使其成为低成本IoT边缘计算的良好选择。
通过适当的存储优化和数据库参数调整，性能还有提升空间。对于规模较大的部署，建议使用4GB内存版本的Raspberry Pi，并配备高性能存储设备。
云服务器测试报告
核心结论
基于本次测试结果，ThingsPanel新架构在1万台设备并发接入的场景下表现出色：
- 单集群支持25000/秒的数据写入，CPU峰值利用率维持在82%以下
- 在高并发下系统各项指标稳定，数据处理无延迟积压
- 基于当前硬件配置，预计可支持40万设备同时接入（按每分钟单设备4个数据点计算）
1. 测试背景与目的
为验证新架构下系统的并发处理能力，搭建了三节点集群环境进行压力测试。本次测试重点关注：
- 系统在高并发环境下的数据处理能力与稳定性
- 集群架构下的资源利用效率
- 系统扩展潜力评估
2. 测试环境
服务器配置
| 机型 | CPU | 内存 | 硬盘 | 说明 |
|---|---|---|---|---|
| 云服务器1 | Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz 4核 | 8GB | ESSD云盘 PL0 40GiB (2280 IOPS) | Cassandra数据库、VerneMQ、数据库和broker的插件应用 |
| 云服务器2 | Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz 4核 | 8GB | ESSD云盘 PL0 40GiB (2280 IOPS) | Cassandra数据库、VerneMQ、数据库和broker的插件应用 |
| 云服务器3 | Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz 4核 | 8GB | ESSD云盘 PL0 40GiB (2280 IOPS) | 应用平台、TimescaleDB、负载均衡器、测试脚本等 |
测试参数设置
- 设备数量：分别以5000台和10000台 设备进行测试
- 数据上报频率：每台设备每6.4秒推送16个数据点
- 测试持续时间：持续运行24小时以验证系统稳定性
3. 测试结果
性能指标数据
| 设备数量 | 写入速度 | CPU使用率（%） | 内存使用率（%） | 内网带宽 | 云盘读写BPS |
|---|---|---|---|---|---|
| 5000台 | 12000/s | 36 / 37 / 40 | 35 / 37 / 17 | 25M | 38M |
| 10000台 | 25000/s | 72 / 73 / 82 | 45 / 48 / 17 | 48M | 76M |
系统稳定性表现
- 数据处理能力：单集群实现25000/秒的持续稳定写入
- 响应时间：Web操作平均响应时间维持在200ms以内
- 队列状态：测试期间broker队列数据处理实时，无积压
- 查询性能：历史数据查询平均响应时间
<500ms
4. 分析与结论
性能分析
-
数据处理能力
- 在1万设备并发场景下，系统维持25000/秒的写入速度，CPU使用率峰值82%，说明系统仍有性能余量
- 数据写入与查询无延迟，表明系统的数据处理管道设计合理
-
资源利用效率
- CPU利用率随设备数量增加呈线性增长，从5000设备时的40%增至1万设备时的82%
- 内存使用率增幅较小（17%→48%），显示内存管理优化效果良好
- 磁盘IO从38M增加到76M，未达到ESSD云盘性能上限
-
网络传输效率
- 内网带宽占用从25M增长到48M，增长比例与设备数量基本匹配
- 网络延迟稳定在个位数毫秒级别，说明集群间通信高效
扩展性评估
基于测试数据，对系统扩展性进行了如下评估：
- 单集群容量：按每分钟单设备4个数据点计算，当前配置理论上可支持40万设备接入
- 横向扩展：通过增加节点，预计系统可线性扩展至百万级设备规模
- 资源瓶颈：当前配置下，CPU使用率是最先达到瓶颈的资源，建议后续扩容优先提升CPU配置
5. 改进建议
-
硬件优化
- 建议升级CPU核心数至8核，以提供更充足的计算资源
- 考虑使用更高性能的ESSD云盘，为未来数据量增长预留空间
-
软件优化
- 优化数据写入批处理机制，减少CPU消耗
- 实现智能负载均衡，提高集群资源利用率
- 增强监控告警机制，提前预警潜在瓶颈
结论
测试表明，ThingsPanel架构具备优秀的并发处理能力和可扩展性。在中等硬件配置下，单集群可稳定支持万级设备接入，为未来支撑更大规模物联网应用奠定了基础。系统在设备数量倍增的情况下，仍保持线性的资源消耗增长，这验证了架构设计的合理性和效能。后续可通过优化资源配置和软件架构，进一步提升系统性能。