Performance 风暴（三叉戟）-卡夫卡-Elasticsearch性能和优化

我有3台机器运行storm supervisors（v0.9.4，每台运行4个Worker），3台机器运行Kafka代理（单个主题，分区=6，复制=2），2台机器运行elasticsearch。每台机器都是4GB双核、3.00GHz的机器；所有设备均通过1Gbps局域网连接

我使用控制台生成器将包含200万个事件（~250MB）的Apache访问日志文件提供给kafka代理。加载到卡夫卡大约需要20秒
与此同时，我的三叉戟拓扑正在运行，当所有200万个事件被编入elasticsearch时，大约7分钟。拓扑由一个trident函数（ExtractData）组成，该函数使用正则表达式提取字段并构造json

问题： （我不相信这个集群目前需要7分钟来索引，大约每秒5千个事件。）

为什么喷口延迟比其他喷口延迟高（参见下图）？（我正在使用OpaqueTridentKafkaSpout）

如果我在16GB RAM和8核机器上运行它，会有显著的区别吗？是否会接近每秒10万个事件

根据我目前的结果，对于任何给定的集群大小和硬件规格（可能是线性关系），是否可以近似计算吞吐量？

以下是我获得的一些配置/统计数据

topology.workers: 12
topology.debug: false
topology.max.spout.pending: 1
topology.message.timeout.secs: 60
topology.trident.batch.emit.interval.millis: 500

---

您可能应该增加topology.max.spout.pending。在trident topology.max.spout.pending中，定义要同时处理的最大批数。在您的情况下，一次只能执行一个批处理。此外，使用topology.trident.batch.emit.interval.millis时，每个批的执行时间将超过500毫秒。这可以解释你的喷口延迟。最后，你应该考虑每台机器每台机器执行1个工作人员。性能的恶化是通过将工人的数量减少到3个（每台机器1个）和增加SPOT。待定到5个（花费了12到15分钟而不是7分钟）。在我的初始配置中将spout.pending增加到5有轻微的改进，但是增加到10或15会再次降低性能（需要8分钟）。emit.interval.millis是喷口协调器上的一个盖子，我认为它应该是一个低值。我试着将它从100毫秒改为1000毫秒，我没有看到任何明显的区别。你解决了这个问题吗？我看到了类似的行为，减少员工数量改善了绩效，但是，只有几分钟。在最初几分钟后，延迟恢复到以前的水平。