Benchmarks

    De vrais runs. De vrais disques. Reproductibles.

    Performances de StreamFlow en débit et latence — mesurées sur le même matériel, avec les outils officiels Kafka, face à Apache Kafka et Redpanda. Aucun mock, aucun fake en mémoire, aucun transport simulé.

    AWS · 3× brokers m6id.2xlargeKafka 3.7 perf-test1M records · 256 B · 16 part.acks=1 · RF=3 · warm
    Comparatif brokers · protocole Kafka

    StreamFlow vs Apache Kafka vs Redpanda

    La seule comparaison honnête : trois backends brokers, les mêmes outils officiels kafka-*-perf-test, le même cluster AWS, l'API Kafka sur :9092.

    Débit produce

    records / seconde · plus haut = mieux
    StreamFlow
    491,642
    Apache Kafka
    487,092
    Redpanda
    488,998
    Lecture honnête — les trois plafonnent à ~490K : le générateur de charge unique est la limite, pas les brokers — c'est donc de la parité, pas une victoire. Le point clé : StreamFlow n'est pas plus lent que Kafka sur le fil Kafka.

    Débit consume

    records / seconde · plus haut = mieux
    StreamFlow
    824,538
    Apache Kafka
    870,447
    Redpanda
    934,602
    Lecture honnête — StreamFlow (~824K) est au niveau de Kafka (~0,95×) et légèrement sous Redpanda. L'écart vient du transcodage de chaque record sur le fil Kafka (le format sur disque de StreamFlow diffère du format wire), alors que Kafka et Redpanda servent via sendfile en zero-copy. Pour le débit brut, voir le protocole natif ci-dessous.
    Latence produce · p99
    9.0 ms
    Les trois brokers à parité (9.0 ms p99) sous la même charge acks=1, RF=3.
    Bande passante produce
    120 MB/s
    StreamFlow 120.0 · Kafka 118.9 · Redpanda 119.4 Mo/s — le plafond NIC client, partagé par les trois.
    Protocole natif · client StreamFlow

    Au-delà du fil Kafka — zéro Kafka dans le chemin

    StreamFlow a son propre transport binaire. Sur le même cluster AWS, hors du protocole Kafka :

    Produce natif · colonnes pipelinées
    4.13 M msg/s
    1.06 Go/s
    Consume natif · livraison complète
    3.31 M msg/s
    847 Mo/s
    Les deux directions sont plafonnées à ~1 Go/s par le NIC du générateur unique, pas par les brokers — un plancher, pas un plafond. Le chemin natif de StreamFlow est ~8× celui du fil Kafka sur le même matériel. Le protocole Kafka est une surface de compatibilité, ce n'est pas le chemin rapide.
    Moteur de stockage · chemin chaud disque local

    Ce que le moteur écrit sur disque

    DirectIOBenchmark — multi-shard, group-commit, vraies écritures disque. Hôte 4 vCPU, Oracle JDK 25, backends FileChannel / Panama FFM.

    Mono-thread
    3.6–3.8 M evt/s
    Un writer, FlatEventBatch → moteur → disque.
    Multi-shard
    8.9–9.3 M ops/s
    Shard-par-cœur, group-commit. io_uring est disponible mais moins bon sur ≤4 vCPU (ses pollers SQPOLL prennent des cœurs aux shards).
    Méthodologie

    Reproduisez vous-même

    Chaque chiffre ci-dessus provient d'un run réel. Voici exactement comment — mêmes outils, même config.

    HardwareAWS · 3× m6id.2xlarge brokers + 1× c6i.xlarge load generator
    ToolsApache Kafka 3.7.0 — kafka-producer-perf-test / kafka-consumer-perf-test
    Workload1,000,000 records · 256-byte payload · 16 partitions
    Durabilityacks=1 · replication factor RF=3 · warm run (JIT hot)
    Broker buildsStreamFlow (this release) · apache/kafka:3.7.0 (KRaft) · redpandadata/redpanda:v24.1.7
    Storage engineDirectIOBenchmark · 4-vCPU · Oracle JDK 25 · FileChannel / Panama FFM

    Une ligne chacun — la CLI livrée enveloppe les deux benchmarks

    bash
    1# storage engine — native disk hot path, every backend, no network, no Kafka
2java -Xmx4g --enable-native-access=ALL-UNNAMED -cp streamflow.jar \
3  com.streamflow.app.cli.StreamFlowCli bench disk
4
5# Kafka wire — stock kafka-clients 3.7.0 against StreamFlow's Kafka port (or any broker)
6java -cp streamflow.jar com.streamflow.app.cli.StreamFlowCli \
7  bench kafka --bootstrap $NODE:9092

    bench disk est la même mesure que le test JUnit DirectIOBenchmark, empaqueté pour tourner depuis le jar. bench kafka utilise les flags canoniques (acks=1, batch.size=65536, linger.ms=5). Lancez chaque benchmark deux fois et reportez le run warm (JIT-hot).

    Mêmes chiffres à la main — outils perf Apache + le dépôt

    bash
    1# produce — 1M records, 256B, acks=1, RF=3 topic
2kafka-producer-perf-test --topic bench --num-records 1000000 --record-size 256 \
3  --throughput -1 --producer-props bootstrap.servers=$NODE:9092 acks=1 \
4  batch.size=65536 linger.ms=5
5
6# consume — same 1M records
7kafka-consumer-perf-test --topic bench --messages 1000000 \
8  --bootstrap-server $NODE:9092
9
10# storage engine — native disk hot path from the StreamFlow repo
11mvn -q -Plarge-heap test -Dtest=DirectIOBenchmark -pl streamflow-core

    Les wrappers CLI ci-dessus et ces commandes brutes mesurent les mêmes chemins — utilisez ce que vous avez sous la main.

    Ce que ces chiffres disent et ne disent pas

    Les nuances honnêtes

    La transparence est le point. Un benchmark non reproductible ou secrètement favorable ne mérite pas d'être publié.

    → Le produce est de la parité client-limitée, pas une victoire.
    Les trois brokers saturent le générateur unique à ~490K rec/s. Cela prouve que StreamFlow tient le rythme de Kafka sur le fil Kafka — rien de plus.
    → Consume ≈ 0,95× Kafka, sous Redpanda.
    Le fetch sur le fil Kafka transcode chaque record ; Kafka/Redpanda utilisent sendfile. Compromis réel, annoncé clairement. Le chemin natif l'évite.
    → io_uring n'est pas toujours plus rapide.
    Sur ≤4 vCPU, ses threads pollers SQPOLL prennent des cœurs aux shards — FileChannel / Panama l'emportent. io_uring paye sur des machines plus grosses.
    → Le débit natif est plafonné par le NIC.
    4,13M / 3,31M msg/s atteignent le NIC ~1 Go/s du client unique, pas une limite broker — un plancher, ajoutez des clients pour aller plus haut.
    → StreamFlow n'est pas basé sur Kafka.
    Le protocole Kafka est une surface de compatibilité. Le moteur est son propre chemin natif, shard-par-cœur, capable io_uring — d'où les chiffres à plusieurs millions d'événements/seconde.
    Voyez par vous-même

    Les chiffres, c'est facile. Faites tourner.

    Montez un cluster, pointez les outils officiels Kafka dessus, et reproduisez le tableau ci-dessus — ou construisez une app live dans le navigateur en 3 minutes.

    Essayer en direct — 3 minutesGuide de reproduction sur GitHub