2、性能指标体系：响应时间、吞吐量、并发数、资源利用率、可用性指标
做SCADA系统性能调优，第一件事不是上手改代码。
而是先搞清楚一件事：你到底要优化什么？
我见过太多团队，一上来就盯着CPU干，结果瓶颈在磁盘IO。或者拼命压并发，结果响应时间飙到用户骂娘。说白了，没有一套清晰的性能指标体系，你就是在黑灯瞎火里修机器。
这一章，我把SCADA系统最核心的五个性能指标掰开揉碎了讲。每个指标背后，都有我踩过的坑。
2.1 响应时间：用户的耐心只有3秒
响应时间，就是从用户发出指令到系统给出反馈的时间。在SCADA里，这个指标尤其敏感。
你想想看，操作员在控制室点一下“关闭阀门”，如果等5秒才有反应，那是什么后果？
我个人习惯把响应时间拆成三段：
- 网络传输时间：数据从客户端到服务器，再回来的时间。一般1-5ms算正常。
- 处理时间：服务器收到请求后，CPU计算、内存读写、数据库查询的时间。这是优化的主战场。
- 排队时间：请求太多，服务器忙不过来，在队列里等着。这个时间一旦出现，说明系统快扛不住了。
实战经验：我在一个水处理项目中遇到过，操作员点“启动水泵”，响应时间从200ms突然跳到8秒。查了半天，发现是历史数据库在做全量归档，把IO吃满了。后来我把归档任务挪到凌晨，问题解决。
响应时间的黄金法则：操作类请求<1秒，画面刷新<3秒，报表查询<10秒。超过这个范围，就得亮红灯了。
2.2 吞吐量：系统能扛多少活
吞吐量，就是单位时间内系统能处理多少请求。在SCADA里，通常用“每秒处理的遥测点数”或“每秒执行的指令数”来衡量。
举个例子：一个变电站SCADA系统，每秒要处理10万个遥测点。如果吞吐量只有8万/秒，那就会有2万个点被丢掉。这在电力行业是绝对不能接受的。
我建议用这个公式估算吞吐量：
吞吐量（点/秒） = 总点数 × 采集频率（次/秒）比如你有5万个点，每2秒采集一次，那吞吐量就是：
50,000 × 0.5 = 25,000 点/秒嗯，这里要注意：吞吐量不是越高越好。盲目提高吞吐量，往往会牺牲响应时间。我见过一个团队把采集频率从1秒改成0.5秒，结果CPU直接飙到95%，响应时间反而变慢了。
我的习惯：先定一个合理的吞吐量目标，然后逐步加压测试。找到那个“吞吐量最高、响应时间还能接受”的平衡点。
2.3 并发数：到底有多少人在用
并发数，就是同一时刻有多少个请求在处理。注意，不是“连接数”，而是“正在处理的请求数”。
SCADA系统的并发场景很特殊：
- 操作员站：几十到几百个客户端同时操作
- 数据采集：成百上千个RTU/PLC同时上报数据
- Web发布：可能还有几百个移动端用户在看画面
我曾经在一个石化项目中踩过坑。系统设计时说支持500并发，结果上线第一天，200个操作员同时登录，系统直接挂了。后来发现，他们把“并发数”和“连接数”搞混了。连接数可以很大，但真正同时处理请求的线程池只有50个。
避坑指南：我曾经以为并发数越大越好，后来发现不是。并发数超过某个阈值，上下文切换的开销会吃掉所有性能。建议用“并发数=CPU核心数×2”作为初始值，然后通过压测找到最佳值。
2.4 资源利用率：CPU、内存、IO、网络
资源利用率，就是系统各个硬件资源的使用情况。这四个资源，任何一个成为瓶颈，都会拖垮整个系统。
| 资源 | 正常范围 | 警戒线 | 我的经验 |
|---|---|---|---|
| CPU | 30%-60% | >80% | CPU高不一定有问题，但持续90%以上肯定要查 |
| 内存 | 60%-70% | >85% | 内存泄漏是SCADA的常见病，我见过一个系统运行3个月后内存占用从4G涨到32G |
| 磁盘IO | IO等待<10% | >30% | 历史数据写入是IO大户，建议用SSD+缓存策略 |
| 网络 | 带宽使用<40% | >70% | 网络延迟比带宽更致命，尤其是跨区域部署时 |
你想想看，如果CPU利用率只有20%，但响应时间很慢，那问题大概率在IO或网络。反过来，CPU飙到95%，内存才用30%，那就要看看是不是有死循环或者频繁的上下文切换。
核心观点：资源利用率不是越低越好，也不是越高越好。关键是找到那个“资源利用率合理、性能达标”的平衡点。我个人习惯把CPU控制在60%左右，留出40%的余量应对突发流量。
2.5 可用性指标：系统到底靠不靠谱
可用性，就是系统能正常提供服务的时间比例。SCADA系统通常要求99.9%以上的可用性，也就是一年宕机时间不超过8.76小时。
但光看这个数字不够。我建议关注三个子指标：
- MTBF（平均无故障时间）：系统能连续运行多久不出故障。好的SCADA系统MTBF应该在8760小时（1年）以上。
- MTTR（平均修复时间）：出故障后，多久能恢复。我见过一个系统MTTR是4小时，但每次故障都发生在半夜，操作员得从家里赶过来，实际恢复时间远不止4小时。
- 故障恢复时间：从故障发生到系统完全恢复的时间。这个指标比MTTR更实际，因为它包括了故障发现、人员响应、修复、验证的全过程。
我的建议：别只看“可用性99.9%”这种漂亮数字。问清楚：
- 故障时数据会不会丢？
- 恢复后历史数据能不能补回来？
- 主备切换时会不会有操作中断？
这些才是SCADA系统可用性的核心。
举个例子：一个水厂SCADA系统，可用性号称99.99%。但每次主备切换时，会有30秒的数据采集中断。这30秒里，如果正好有水位报警，就可能被漏掉。你说这算不算可用性问题？
2.6 五个指标的关系：一个都不能少
这五个指标不是孤立的。它们之间互相影响，甚至互相矛盾。
比如：
- 提高并发数，响应时间可能会变慢
- 降低响应时间，可能需要牺牲吞吐量
- 提高资源利用率，可用性可能会下降（因为没留余量）
我习惯用这个“性能五边形”来评估系统：
响应时间
↑
|
吞吐量 ← + → 并发数
|
↓
资源利用率
|
↓
可用性任何一个指标出问题，都要看看其他四个指标有没有异常。比如响应时间变慢，可能是并发数太高，也可能是资源利用率爆了，还可能是可用性出了问题（比如主备切换导致性能下降）。
总结：性能调优不是单点优化，而是系统性的平衡。这五个指标，就是你的仪表盘。每次调优前，先看看这五个表针指在哪里。方向对了，调优才能事半功倍。
下一章，我会讲怎么用工具把这些指标抓出来。嗯，工欲善其事，必先利其器嘛。