用三个具体指标定位Storm性能瓶颈，而不是凭感觉调优

Storm的UI为每个Topology提供了详细的统计信息，其中三个参数对定位性能瓶颈特别有参考价值。Execute latency（执行延迟）：消息的平均处理时间，单位毫秒，反映单条消息在这个组件内部真正被处理花了多长时间。Process latency（处理延迟）：消息从被收到到被ACK掉所花的总时间，单位毫秒——如果没有启用Acker机制，这个值恒为0，它反映的是包含了排队等待在内的端到端延迟，而不只是纯粹的执行耗时。Capacity（容量）：计算公式是”Bolt或Executor调用execute方法处理的消息数量×消息平均执行时间÷时间区间”，这个值如果接近1，意味着这个组件几乎一直在忙于执行execute方法、没有空闲时间，直接说明这个组件的并行度不够，需要给它增加更多Executor来分担负载。这三个指标组合起来，能够精确定位性能问题究竟出在哪个环节：如果某个组件的Execute latency本身就很高，说明问题出在这个组件内部逻辑的执行效率上，需要优化具体的处理代码；如果Execute latency不高但Process latency明显偏高，说明消息在队列里排队等待的时间过长，问题更可能出在上下游的处理速度不匹配上；如果Capacity长期接近1，说明这不是逻辑效率的问题，而是这个组件的并行度设置得太低、扛不住当前的流量，需要横向扩容。这个案例给出的核心方法论是：性能优化必须建立在具体可观测的量化指标之上，而不是凭主观直觉去猜测”哪里可能慢”——这三个指标各自反映了性能问题的不同侧面（纯执行效率、端到端延迟、并行度是否充足），组合起来使用能够把一个笼统的”这个Topology跑得慢”，精确拆解成”具体是哪个组件、因为哪种原因导致的慢”，从而让后续的优化动作有明确、有依据的落脚点，而不是在猜测中反复试错。