1

EC2 サーバーで 1k サイズのメッセージをストリーミングして、Kafka 0.8.1.1 のベンチマークを行っています。

2 つの m3.xlarge サーバーに Zookeeper をインストールし、次の構成を使用しました。

dataDir=/var/zookeeper/                                                                    
clientPort=2181
initLimit=5
syncLimit=2
server.server1=zoo1:2888:3888                                
server.server2=zoo2:2888:3888

次に、32Gb RAM と追加の 6 つの SSD ドライブを備えた i2.2xlarge マシンに単一の Kafka サーバーをインストールし、各ディスクは としてパーティション分割されまし/mnt/a , mnt/b, etc....た。サーバーには、ブローカーが 1 つ、ポート 9092 にトピックが 1 つ、レプリケーション ファクターが 1 の 8 つのパーティションがあります。

broker.id=1
port=9092
num.network.threads=4
num.io.threads=8
socket.send.buffer.bytes=1048576
socket.receive.buffer.bytes=1048576
socket.request.max.bytes=104857600
log.dirs=/mnt/a/dfs-data/kafka-logs,/mnt/b/dfs-data/kafka-logs,/mnt/c/dfs-data/kafka-logs,/mnt/d/dfs-data/kafka-logs,/mnt/e/dfs-data/kafka-logs,/mnt/f/dfs-data/kafka-logs
num.partitions=8
log.retention.hours=168
log.segment.bytes=536870912
log.cleanup.interval.mins=1
zookeeper.connect=172.31.26.252:2181,172.31.26.253:2181
zookeeper.connection.timeout.ms=1000000
kafka.metrics.polling.interval.secs=5
kafka.metrics.reporters=kafka.metrics.KafkaCSVMetricsReporter
kafka.csv.metrics.dir=/tmp/kafka_metrics
kafka.csv.metrics.reporter.enabled=false
replica.lag.max.messages=10000000

すべてのテストは別のインスタンスから実行され、インスタンス間のレイテンシは 1 ミリ秒未満です。パーティション キーが 0 から 7 までの乱数である場合、1 つのスレッド プロデューサーと 8 つのスレッド コンシューマーを使用してプロデューサー/コンシューマー Java クライアントを作成しました。カスタム エンコーダーを提供することで、Json を使用して各メッセージをシリアル化しました。

私の消費者プロデューサーのプロパティは次のとおりです。

metadata.broker.list = 172.31.47.136:9092
topic = mytopic
group.id = mytestgroup
zookeeper.connect = 172.31.26.252:2181,172.31.26.253:2181
serializer.class = com.vanilla.kafka.JsonEncoder
key.serializer.class = kafka.serializer.StringEncoder
producer.type=async
queue.enqueue.timeout.ms = -1
batch.num.messages=200
compression.codec=0
zookeeper.session.timeout.ms=400
zookeeper.sync.time.ms=200
auto.commit.interval.ms=1000
number.messages = 100000

100k メッセージを送信すると、1 秒あたり 10k メッセージの容量と約 1 ミリ秒の遅延が発生します。

これは毎秒 10 メガバイト、つまり 80Mb/s であることを意味します。これは悪くありませんが、同じゾーンに配置されたインスタンスからはより良いパフォーマンスが期待できます。

構成に何か不足していますか?

4

2 に答える 2

3

問題を分解することをお勧めします。JSON エンコーディングを使用しない場合の速度。レプリケーションなしとレプリケーションありの場合の 1 つのノードの速度。各コンポーネントがどれだけ速くあるべきかについてのイメージを構築します。
また、ベアメタルマシンをテストして、大幅に高速になる可能性があるため、それらを比較することをお勧めします（CPUバウンドの場合を除き、ほとんど同じになる可能性があります）。

このベンチマークによると、1 つのノードから 50 MB/s を取得できるはずですhttp://kafka.apache.org/07/performance.html

1Gbリンクを飽和状態に近づけることができるはずです（それがあなたが持っているものだと思います）

免責事項：私はかなり高速なChronicle Queueに取り組んでいますhttp://java.dzone.com/articles/kafra-benchmark-chronicle

于 2014-12-12T17:09:48.957 に答える
1

アプリケーションにとって意味がある場合は、JSON オブジェクトの代わりにバイト配列をストリーミングすることでパフォーマンスを向上させ、パイプラインの最後のステップでバイト配列を JSON オブジェクトに変換できます。

また、各コンシューマ スレッドが同じトピック パーティションから一貫して読み取る場合、パフォーマンスが向上する可能性があります。Kafka では、一度に 1 つのコンシューマーのみがパーティションから読み取ることができると思います。そのため、パーティションをランダムに選択する方法によっては、別のコンシューマー スレッドと同じパーティションから読み取ろうとすると、コンシューマーが一時的にブロックされる可能性があります。

また、コンシューマ スレッドを少なくしたり、kafka バッチ サイズを変えたりすることで、パフォーマンスを向上できる可能性もあります。パラメーター化された JUnit テストを使用して、コンシューマーごとのスレッド数やバッチ サイズなどの最適な設定を見つけます。その概念を説明するために私が書いたいくつかの例を次に示します。

http://www.bigendiandata.com/2016-10-02-Junit-Examples-for-Kafka/ https://github.com/iandow/kafka_junit_tests

それが役立つことを願っています。

于 2016-10-07T17:02:05.393 に答える