去年花了大半年的时间在Fregata项目上,目前的部署规模在12000个docker的水平。今年上半年打算

对Fregata项目进行一次框架上的升级,目标是提升性能,为上下游生态系统减负。

拓扑

旧拓扑

之前的拓扑是树形拓扑,意味下游节点的并行度不能低于上游的,至少保持一致。

1个Source,3个Parser,3个Sink,Parser和Sink一一对应,数据不会交叉。

1个Source,3个Parser,6个Sink,每个Parser后面对应2个Sink。

新拓扑

新拓扑中的Parser可以将数据分发给任何一个Sink。

1个Source,2个Parser,5个Sink 每个Parser后面都对应5个Sink。

通过控制数据的离散规则可以达到旧拓扑的效果,也就是说,旧拓扑是新拓扑的一种特例。

好处

通过更加合理的配比,达到最小资源和最大性能,举例说明:

老:1×Source + 5×Parser + 5×Sink = 11×Component

新:1×Source + 3×Parser + 6×Sink = 10×Component

在我们的测试中,新拓扑方案比老的快20%,因为整个Stream的瓶颈在Sink,Parser只需要3个就可以。

在减少component的情况下,性能依然得到的提升,减少component,意味着线程数的减少,

buffer区个数会减少,内存预分配的占用也会减少。

Buffer

在这次调优过程中,我们测试了buffer的大小,前后比例对性能的影响。

buffer超过1024后,对性能的提升帮助不大,前提是sink端的性能相对稳定。

source到parser间的buffer设置的更大一下,更有利于性能的稳定。

KafkaSink

老版里我们在Sink上抽象了一层BatchSink,这次重构我们将Batch的逻辑全部交给Kafka的

Client去处理,利用它的linger和batchsize等操作。性能得到20%-30%的提升。

我们对Kafka的Producer也进行了大量的测试,如果我们最大限度的让Producer积攒数据,

会让数据的体积更小,网络和磁盘的开销都会有2-3倍的节约,在消费解压时也会更快。

SpinTime

在老版里,我们就使用SpinTime来进行系统性能的预警,在新版里我们主要使用Spintime来进行

自动伸缩容的评判,目前还在测试中。