最近我们的storm在跑的过程中, 发现bolt的complete latency都非常低, 在1ms以下, 而spout却不断的增加, 达到了好几千ms, 最后导致整个spout挂掉(后来发现complete latency不断增加跟fail有关). 这是一个非常严重的问题, 于是在storm-user上google了一把, 发现这里([url=http://groups.google.com/group/storm-user/browse_thread/thread/8efc088b8b1c5aca/0f0f8dc7f8a6aa05?lnk=gst&q=complete+latency+long#]1[/url],[url=http://groups.google.com/group/storm-user/browse_thread/thread/2d801dd33c0c175b]2[/url])已经有了一些答案.
nathan对complete latency也做了一个非常详细的解释:
complete latency(这里主要针对spout)是一个tuple从发出, 到经过bolt处理完成, 最终调用spout的ack这个完整的过程所花的时间.
complete latency和吞吐量可以认为是互斥的, 二者不可兼得, 要提高吞吐量, 必然会增加complete latency, 反之亦然. 所以我们需要根据具体的场景, 在二者之间找到一个平衡.
complete latency受到两个因素的影响:
bolt的处理时间
spout的parallelism数量
关于latency的计算方式, [url=http://groups.google.com/group/storm-user/browse_thread/thread/32cae04a782a46d6]这里[/url]也有说明, 即一个tuple从被接收到被ack所花的时间.
nathan对complete latency也做了一个非常详细的解释:
complete latency(这里主要针对spout)是一个tuple从发出, 到经过bolt处理完成, 最终调用spout的ack这个完整的过程所花的时间.
complete latency和吞吐量可以认为是互斥的, 二者不可兼得, 要提高吞吐量, 必然会增加complete latency, 反之亦然. 所以我们需要根据具体的场景, 在二者之间找到一个平衡.
complete latency受到两个因素的影响:
bolt的处理时间
spout的parallelism数量
关于latency的计算方式, [url=http://groups.google.com/group/storm-user/browse_thread/thread/32cae04a782a46d6]这里[/url]也有说明, 即一个tuple从被接收到被ack所花的时间.