先找瓶颈再调参
多数代理的性能瓶颈并不在协议处理，而在每连接内存、订阅树规模、磁盘写入与操作系统层面的资源上限。调优的起点是压测出当前基线：多少连接、多少订阅、每秒多少消息、尾部延迟多高；然后定位第一个被打满的资源，再针对它调整参数并复测。
基本信息
| 容量维度 | 并发连接数、订阅关系数、消息吞吐、离线消息积压量 |
|---|---|
| 内存大头 | 每连接的会话与缓冲、订阅树、积压的 QoS 1 与 QoS 2 消息 |
| 磁盘压力 | 持久会话与保留消息的写入、日志与快照的落盘策略 |
| 系统层面 | 文件描述符上限、内核连接队列、Socket 缓冲区、系统调用开销 |
| 调优顺序 | 压测基线、定位瓶颈、调整参数、复测确认，不跨产品套用参数 |
常见瓶颈与方向
| 瓶颈 | 现象 | 调整方向 |
|---|---|---|
| 每连接内存偏高 | 连接数上不去，内存先耗尽 | 评估会话与缓冲配置，限制持久会话数量 |
| 订阅树膨胀 | 通配符订阅响应变慢 | 收敛主题粒度，减少过宽的通配符订阅 |
| 磁盘写入瓶颈 | 延迟随吞吐上升 | 区分可靠投递与可丢数据，分别选择落盘策略 |
| 文件描述符耗尽 | 新连接随机失败 | 提高系统上限，排查连接未释放的原因 |
典型使用场景
- 上线前容量规划：按预期连接数与消息速率压测，留出余量
- 扩容判断：区分是代理瓶颈还是下游消费者处理不过来
- 故障复盘：连接随机失败时先看文件描述符与内存两类指标
- 成本优化：把可丢数据从高 QoS 与落盘中移出，换取更低的资源占用
不同代理实现的参数体系差别很大，任何具体参数名与默认值都应以所用代理的官方文档为准，不要跨产品套用经验值。
把持久会话数量放开是常见的资源陷阱：离线设备积压的消息会持续占用内存与磁盘，直到服务端无法接受新连接。