Apache storm 确认时风暴拓扑性能受到影响

我正在使用yahoo的这个工具在我的storm集群上运行一些性能测试-

我注意到，当我打开acking时，性能几乎达到10倍。下面是一些复制测试的细节- 簇- 3个监控节点和1个nimbus节点。每个节点都是一个c3.1大节点

带acking-

bin/storm jar storm_perf_test-1.0.0-SNAPSHOT-jar-with-dependencies.jar com.yahoo.storm.perftest.Main--ack--boltParallel 60--maxpoutpending 100--messageSizeByte 100--name一些拓扑--numWorkers 9--spoutParallel 20--testTimeSec 100--pollFreqSec 20--numLevels 2

status  topologies  totalSlots  slotsUsed   totalExecutors  executorsWithMetrics    time    time-diff ms    transferred throughput (MB/s)
WAITING 1   3   0   141 0   1424707134585   0   0   0.0
WAITING 1   3   3   141 141 1424707154585   20000   24660   0.11758804321289062
WAITING 1   3   3   141 141 1424707174585   20000   17320   0.08258819580078125
RUNNING 1   3   3   141 141 1424707194585   20000   13880   0.06618499755859375
RUNNING 1   3   3   141 141 1424707214585   20000   21720   0.10356903076171875
RUNNING 1   3   3   141 141 1424707234585   20000   43220   0.20608901977539062
RUNNING 1   3   3   141 141 1424707254585   20000   35520   0.16937255859375
RUNNING 1   3   3   141 141 1424707274585   20000   33820   0.16126632690429688

status  topologies  totalSlots  slotsUsed   totalExecutors  executorsWithMetrics    time    time-diff ms    transferred throughput (MB/s)
WAITING 1   3   0   140 0   1424707374386   0   0   0.0
WAITING 1   3   3   140 140 1424707394386   20000   565460  2.6963233947753906
WAITING 1   3   3   140 140 1424707414386   20000   1530680 7.298851013183594
RUNNING 1   3   3   140 140 1424707434386   20000   3280760 15.643882751464844
RUNNING 1   3   3   140 140 1424707454386   20000   3308000 15.773773193359375
RUNNING 1   3   3   140 140 1424707474386   20000   4367260 20.824718475341797
RUNNING 1   3   3   140 140 1424707494386   20000   4489000 21.40522003173828
RUNNING 1   3   3   140 140 1424707514386   20000   5058960 24.123001098632812

无应答-

bin/storm jar~/target/storm_perf_test-1.0.0-SNAPSHOT-jar-with-dependencies.jar com.yahoo.storm.perftest.Main--boltParallel 60--maxpoutpending 100--messageSizeByte 100--name一些拓扑--numWorkers 9--spoutParallel 20--testTimeSec 100--pollFreqSec 20--numLevels 2

status  topologies  totalSlots  slotsUsed   totalExecutors  executorsWithMetrics    time    time-diff ms    transferred throughput (MB/s)
WAITING 1   3   0   141 0   1424707134585   0   0   0.0
WAITING 1   3   3   141 141 1424707154585   20000   24660   0.11758804321289062
WAITING 1   3   3   141 141 1424707174585   20000   17320   0.08258819580078125
RUNNING 1   3   3   141 141 1424707194585   20000   13880   0.06618499755859375
RUNNING 1   3   3   141 141 1424707214585   20000   21720   0.10356903076171875
RUNNING 1   3   3   141 141 1424707234585   20000   43220   0.20608901977539062
RUNNING 1   3   3   141 141 1424707254585   20000   35520   0.16937255859375
RUNNING 1   3   3   141 141 1424707274585   20000   33820   0.16126632690429688

status  topologies  totalSlots  slotsUsed   totalExecutors  executorsWithMetrics    time    time-diff ms    transferred throughput (MB/s)
WAITING 1   3   0   140 0   1424707374386   0   0   0.0
WAITING 1   3   3   140 140 1424707394386   20000   565460  2.6963233947753906
WAITING 1   3   3   140 140 1424707414386   20000   1530680 7.298851013183594
RUNNING 1   3   3   140 140 1424707434386   20000   3280760 15.643882751464844
RUNNING 1   3   3   140 140 1424707454386   20000   3308000 15.773773193359375
RUNNING 1   3   3   140 140 1424707474386   20000   4367260 20.824718475341797
RUNNING 1   3   3   140 140 1424707494386   20000   4489000 21.40522003173828
RUNNING 1   3   3   140 140 1424707514386   20000   5058960 24.123001098632812

最后两列才是真正重要的。它显示传输的元组数和速率（以MBps为单位）

---

当我们打开acking时，这种性能会受到风暴的影响吗？我使用的是0.9.3版，没有高级网络功能。

启用确认功能后，性能总会有一定程度的下降——这是您为可靠性付出的代价。在禁用确认的情况下，吞吐量始终会更高，但您无法保证数据是否被处理或丢弃在地板上。无论这是一个10倍的点击率，如你所见，或显着减少，是一个调整的问题

一个重要的设置是topology.max.spout.pending，它允许您对喷口进行节流，以便在任何给定时间只允许有那么多元组处于“飞行”状态。该设置有助于确保下游螺栓不会不知所措，并开始计时元组

该设置在禁用acking时也没有效果——就像打开防淹门并丢弃溢出的任何数据一样。因此，它总是更快

启用确认后，Storm将确保所有内容都至少处理一次，但您需要针对您的用例适当地调优拓扑.max.spout.pending。因为每个用例都是不同的，所以这是一个反复试验的问题。将其设置得太低，吞吐量就会很低。设置得太高，你的下游螺栓会被压垮，元组会超时，你会得到回放

为了举例说明，将

maxpoutpending

设置为1，然后再次运行基准测试。然后试试1000

---

因此，是的，如果没有适当的调整，性能可以达到10倍。如果数据丢失对于您的用例来说是正常的，那么关闭确认。但是，如果您需要可靠的处理，请打开它，根据您的用例进行调整，并水平扩展（添加更多节点）以达到吞吐量要求。

您会遇到多少失败？可能有些元组在等待ACK并重新提交时超时。没有失败。谢谢PTG。我还要补充一点，增加

topology.acker.executors

的数量有助于略微提高吞吐量。在玩了

maxpoutpending

之后，我发现1000对于我的集群和消息大小来说是最佳的。除此之外，我开始失败。然而，当我增加ACKER的数量时，吞吐量的大量增加发生了。