Guide d’optimisation des performances Kafka : Producer, Consumer et Broker

 

Apache Kafka est conçu pour offrir un streaming d’événements à haut débit et à faible latence. Cependant, utiliser Kafka avec sa configuration par défaut ne garantit pas automatiquement des performances optimales.

Un cluster Kafka capable de traiter efficacement quelques milliers de messages par seconde peut se comporter très différemment lorsque le trafic atteint des centaines de milliers, voire des millions d’événements.

L’optimisation des performances Kafka nécessite de comprendre l’ensemble du flux de données :

Producer → Partitions du Topic → Brokers Kafka → Consumer Groups

Les problèmes de performance peuvent apparaître à n’importe quelle étape de cette chaîne.

Dans ce guide pratique, nous allons voir comment optimiser :

• les Kafka Producers ;
• les Kafka Consumers ;
• les Kafka Brokers ;
• les partitions des topics ;
• le batching des messages ;
• la compression ;
• la réplication ;
• le consumer lag ;
• l’utilisation du disque et du réseau ;
• les ressources JVM et système ;
• la surveillance des performances Kafka.

L’objectif n’est pas simplement de rendre Kafka « plus rapide ». Il s’agit de trouver le bon équilibre entre débit, latence, durabilité et utilisation des ressources.

English version: https://shikhanirankari.blogspot.com/2026/08/kafka-performance-tuning-guide.html

🎥 Vidéo : Kafka Consumer Groups Explained

Vous préférez une explication visuelle ? Découvrez ma vidéo sur les Kafka Consumer Groups, les partitions, les offsets et le rebalancing.
▶ Regarder la vidéo sur YouTube

---

Architecture des performances Kafka

Avant d’optimiser des paramètres individuels, il est important de considérer le flux complet des événements.

Applications Producer

↓

Topic Kafka

↓

Partitions

↓

Brokers Kafka

↓

Consumer Group

↓

Applications en aval

Un producer envoie des enregistrements vers les partitions d’un topic. Les brokers Kafka reçoivent, stockent et répliquent ces données. Les consumers récupèrent ensuite les enregistrements depuis les partitions qui leur sont attribuées.

Une baisse des performances Kafka peut donc provenir de plusieurs sources :

• batching insuffisant côté producer ;
• bande passante réseau limitée ;
• distribution déséquilibrée des partitions ;
• performances disque des brokers ;
• surcharge liée à la réplication ;
• parallélisme insuffisant des consumers ;
• traitement lent dans les applications en aval.

L’optimisation Kafka doit donc être réalisée de bout en bout, et non paramètre par paramètre.

---

1. Établir d’abord une référence de performance Kafka

L’une des erreurs les plus fréquentes consiste à modifier les paramètres Kafka avant même de mesurer les performances actuelles.

Commencez toujours par établir une baseline.

Les métriques importantes comprennent :

Métrique	Ce qu’elle indique
Producer throughput	Vitesse de publication des données
Producer latency	Temps nécessaire pour confirmer une écriture
Records/sec	Nombre d’événements traités par seconde
Bytes/sec	Débit de données
Consumer throughput	Vitesse de traitement des consumers
Consumer lag	Retard des consumers par rapport aux producers
Broker CPU	Charge CPU des brokers
Disk utilization	Pression sur le stockage
Network utilization	Saturation du réseau
Request latency	Temps de réponse broker/client

Kafka fournit notamment des outils de test de performance :

kafka-producer-perf-test.sh

et :

kafka-consumer-perf-test.sh

Utilisez ces tests avant et après chaque modification importante.

Le processus d’optimisation devrait suivre cette logique :

Mesurer → Identifier le goulot d’étranglement → Optimiser → Tester → Comparer → Répéter

Une configuration efficace dans un environnement Kafka ne donnera pas nécessairement les mêmes résultats dans un autre.

---

2. Optimisation des performances du Kafka Producer

Le producer est l’un des premiers composants à analyser lorsque le débit d’écriture Kafka est inférieur aux attentes.

Plusieurs propriétés influencent directement ses performances.

2.1 Optimiser batch.size

Kafka n’envoie pas nécessairement chaque message individuellement.

Les messages destinés à une même partition peuvent être regroupés en lots.

batch.size=65536

Des batches plus importants peuvent :

• réduire le nombre de requêtes réseau ;
• améliorer la compression ;
• augmenter le throughput.

Cependant, des batches trop importants peuvent augmenter la consommation mémoire et influencer la latence.

Pour les workloads orientés débit, testez progressivement différentes tailles plutôt que de sélectionner immédiatement une valeur très élevée.

---

2.2 Optimiser linger.ms

linger.ms contrôle le temps pendant lequel le producer peut attendre l’arrivée de messages supplémentaires avant d’envoyer un batch.

linger.ms=10

Une courte attente permet souvent de regrouper davantage de messages.

Le compromis est simple :

Valeur linger.ms faible

→ moins d’attente
→ batches potentiellement plus petits

Valeur linger.ms plus élevée

→ meilleur batching
→ throughput potentiellement supérieur
→ latence potentiellement supérieure

Pour les systèmes à haut débit, des valeurs telles que 5 à 20 ms peuvent servir de point de départ pour les benchmarks. La valeur optimale dépend toutefois du workload.

---

2.3 Activer la compression

La compression peut réduire considérablement le trafic réseau et les besoins de stockage.

compression.type=lz4

Les options courantes incluent :

none
gzip
snappy
lz4
zstd

Pour de nombreux workloads Kafka à haut débit, LZ4 offre un bon équilibre entre vitesse et compression.

zstd peut fournir un meilleur taux de compression et mérite d’être testé lorsque la bande passante réseau ou le stockage représente une contrainte importante.

Il ne faut cependant pas choisir un algorithme uniquement en fonction de son taux de compression.

Mesurez également :

• le CPU du producer ;
• le CPU du broker ;
• la bande passante ;
• la latence end-to-end ;
• l’utilisation du stockage.

---

2.4 Comprendre acks

Le paramètre acks contrôle le niveau de confirmation demandé par le producer.

acks=all

Avec acks=all, le producer attend les confirmations correspondant aux exigences de réplication du système.

Cette configuration offre une meilleure durabilité que :

acks=1

où seul le leader de la partition doit confirmer l’écriture.

Le choix doit donc être déterminé par les exigences métier et de fiabilité, et non uniquement par le throughput maximal obtenu lors d’un benchmark.

---

2.5 Activer l’idempotence lorsque nécessaire

Lorsque les doublons causés par les retries ne sont pas acceptables :

enable.idempotence=true

L’idempotence permet d’éviter certains enregistrements dupliqués provoqués par les nouvelles tentatives du producer.

Cette fonctionnalité est particulièrement importante pour les événements liés aux paiements, aux workflows et aux intégrations d’entreprise.

---

2.6 Optimiser la mémoire tampon du Producer

Le producer conserve temporairement les messages en mémoire avant leur envoi.

buffer.memory=67108864

Si les applications produisent des événements plus rapidement que Kafka ne peut les accepter, une mémoire tampon insuffisante peut provoquer des blocages.

Mais augmenter continuellement buffer.memory ne résout pas nécessairement le problème.

Une pression persistante peut indiquer :

• des brokers trop lents ;
• un problème réseau ;
• un nombre insuffisant de partitions ;
• du throttling ;
• une saturation du cluster.

---

Configuration Producer de départ

Une configuration orientée throughput à tester pourrait être :

bootstrap.servers=kafka1:9092,kafka2:9092,kafka3:9092

acks=all

enable.idempotence=true

batch.size=65536

linger.ms=10

compression.type=lz4

buffer.memory=67108864

Ces valeurs doivent être considérées comme un point de départ pour vos benchmarks, et non comme une configuration universelle.

---

3. Optimisation des performances du Kafka Consumer

L’optimisation du producer ne représente qu’une partie du problème.

Un cluster peut accepter des millions d’événements alors que ses consumers prennent continuellement du retard.

L’un des indicateurs les plus importants est :

Consumer Lag

Le consumer lag représente la différence entre le dernier offset disponible dans une partition et l’offset déjà traité par le consumer.

Une augmentation continue du lag signifie que les consumers ne suivent pas le rythme des producers.

---

3.1 Optimiser fetch.min.bytes

Ce paramètre indique la quantité minimale de données que le broker essaie de retourner dans une réponse de fetch.

fetch.min.bytes=65536

Une valeur supérieure peut réduire le nombre de petites requêtes et améliorer le throughput.

En revanche, attendre davantage de données peut augmenter la latence lorsque le volume d’événements est faible.

---

3.2 Optimiser fetch.max.wait.ms

Ce paramètre détermine combien de temps le broker peut attendre pour tenter de satisfaire fetch.min.bytes.

fetch.max.wait.ms=500

Ces deux propriétés doivent donc être analysées ensemble :

fetch.min.bytes
fetch.max.wait.ms

Pour les workloads à haut débit, des fetches plus importants peuvent être plus efficaces que de nombreuses petites requêtes.

---

3.3 Optimiser max.poll.records

Ce paramètre contrôle le nombre maximal d’enregistrements retournés par un appel à poll().

max.poll.records=500

Une valeur plus importante peut améliorer l’efficacité du traitement par batch.

Cependant, si le traitement prend trop de temps, le consumer peut dépasser l’intervalle de polling autorisé.

Cela peut entraîner un :

Consumer Rebalance

Des rebalances fréquents peuvent fortement dégrader les performances.

---

3.4 Optimiser max.poll.interval.ms

Lorsque le traitement des messages est relativement long :

max.poll.interval.ms=300000

Mais il ne faut pas simplement augmenter cette valeur pour masquer un problème de performance.

Recherchez plutôt les causes possibles :

• appels à une base de données ;
• appels REST ;
• services externes ;
• transformations complexes ;
• traitement synchrone ;
• stockage lent ;
• nombre insuffisant de threads.

---

4. Augmenter le parallélisme des Consumers

La capacité de Kafka à évoluer horizontalement repose largement sur les partitions.

Dans un consumer group :

une partition ne peut être consommée activement que par un seul consumer du groupe à un instant donné.

Supposons qu’un topic possède :

6 partitions

et que le consumer group contienne :

3 consumers

Kafka peut attribuer environ deux partitions à chaque consumer.

Avec six consumers, chaque consumer peut potentiellement recevoir une partition.

En revanche, si vous déployez :

10 consumers

pour seulement six partitions, quatre consumers supplémentaires n’apportent aucun parallélisme au niveau des partitions.

Ainsi :

Parallélisme maximal utile ≈ nombre de partitions

---

5. Optimisation des partitions Kafka

Les partitions fournissent du parallélisme aux producers et aux consumers.

Un nombre plus élevé de partitions peut augmenter le throughput en répartissant la charge entre plusieurs brokers.

Mais :

plus de partitions ne signifie pas toujours de meilleures performances.

Chaque partition entraîne une certaine surcharge :

• métadonnées ;
• fichiers ouverts ;
• réplication ;
• gestion des leaders ;
• récupération ;
• mémoire ;
• trafic réseau.

Le nombre approprié dépend notamment :

• du throughput attendu ;
• du nombre de consumers ;
• de la capacité des brokers ;
• de la taille des messages ;
• de la rétention ;
• du facteur de réplication ;
• de la croissance prévue.

Le partitionnement doit donc résulter d’un véritable capacity planning.

---

6. Éviter les Hot Partitions

Même avec de nombreuses partitions, une mauvaise stratégie de clé peut déséquilibrer le trafic.

Supposons qu’une grande majorité des messages utilisent la même clé :

customerType=DEFAULT

Si cette clé est toujours affectée à la même partition, celle-ci peut recevoir beaucoup plus de trafic que les autres.

On obtient alors une :

Hot Partition

Les symptômes peuvent inclure :

• CPU très élevé sur un broker ;
• utilisation disque déséquilibrée ;
• augmentation de la latence producer ;
• consumer lag élevé sur certaines partitions.

Une bonne clé de partitionnement doit permettre à la fois :

1. de respecter les exigences d’ordre ;
2. de distribuer raisonnablement la charge.

---

7. Optimisation des Kafka Brokers

Lorsque les producers et consumers sont correctement configurés mais que les performances restent insuffisantes, analysez les brokers.

Les performances d’un broker Kafka dépendent principalement de :

CPU + Mémoire + Disque + Réseau

7.1 Performance disque

Kafka écrit continuellement les événements sur disque.

Un stockage lent peut devenir un goulot d’étranglement important.

Pour les workloads de production à haut débit, des SSD/NVMe rapides peuvent offrir de meilleures performances que des disques plus lents.

Surveillez :

• la latence disque ;
• l’utilisation disque ;
• le throughput lecture/écriture ;
• l’I/O wait.

---

7.2 Linux Page Cache

Kafka utilise fortement le cache de pages du système d’exploitation.

Attribuer presque toute la mémoire du serveur au heap JVM peut donc être contre-productif.

Une quantité suffisante de RAM doit rester disponible pour que le système d’exploitation puisse mettre en cache les segments de logs fréquemment utilisés.

---

7.3 Capacité réseau

Kafka peut générer beaucoup plus de trafic réseau que le volume initial envoyé par les producers.

Les données circulent notamment :

Producer → Broker Leader

puis :

Leader → Replica Brokers

et ensuite :

Broker → Consumers

Surveillez donc :

Network In
Network Out
Request Latency
Request Queue
Replication Traffic

Une saturation réseau peut limiter Kafka même lorsque le CPU et le disque semblent fonctionner normalement.

---

8. Optimisation des threads Broker

Deux propriétés peuvent être analysées sous forte charge :

num.network.threads

et :

num.io.threads

Les network threads gèrent les requêtes réseau, tandis que les I/O threads participent au traitement des requêtes pouvant impliquer des opérations disque.

Augmenter ces valeurs peut être utile lorsque les métriques démontrent clairement un goulot d’étranglement.

Mais davantage de threads peuvent également augmenter :

• la consommation CPU ;
• la mémoire ;
• les changements de contexte.

Optimisez uniquement à partir de mesures réelles.

---

9. Replication Factor vs Performance

La réplication assure la tolérance aux pannes.

Une configuration courante en production est :

replication.factor=3

Plusieurs copies des partitions sont alors conservées sur différents brokers.

Cette approche améliore la disponibilité et la durabilité, mais consomme également :

• du stockage ;
• de la bande passante ;
• des ressources broker.

Il est déconseillé de réduire la réplication uniquement pour améliorer un résultat de benchmark si cela compromet les exigences de fiabilité.

---

10. Optimisation de la taille des messages Kafka

Des messages Kafka très volumineux peuvent dégrader les performances.

Ils augmentent :

• le temps de transfert réseau ;
• les besoins mémoire ;
• la pression sur les buffers ;
• la consommation des brokers ;
• les besoins de fetch des consumers.

Lorsque cela est possible, conservez des événements relativement compacts.

Au lieu de placer directement un fichier volumineux dans Kafka, stockez-le dans une solution adaptée et transmettez une référence.

{
  "documentId": "DOC-10001",
  "location": "/documents/DOC-10001.pdf",
  "eventType": "DOCUMENT_CREATED"
}

---

11. Stratégie de compression Kafka

La compression peut améliorer les performances lorsque le réseau constitue un goulot d’étranglement.

Conceptuellement :

100 MB d'événements
        ↓
Compression
        ↓
Payload réseau réduit
        ↓
Kafka Broker

Un meilleur batching peut également améliorer l’efficacité de la compression.

Cependant, la compression utilise du CPU.

Il faut donc comparer :

économie réseau vs coût CPU

avant de sélectionner une stratégie.

---

12. Optimisation du Consumer Lag

Le consumer lag est l’une des métriques opérationnelles Kafka les plus importantes.

Exemple :

Latest Offset = 1 000 000
Consumer Offset = 850 000

Donc :

Consumer Lag = 150 000

Si le lag augmente continuellement, les consumers ne peuvent pas traiter les événements aussi rapidement qu’ils sont produits.

Solutions possibles :

• augmenter le nombre de consumers ;
• augmenter le nombre de partitions lorsque cela est justifié ;
• optimiser le traitement ;
• regrouper les opérations de base de données ;
• réduire les appels synchrones inutiles ;
• optimiser les API en aval ;
• améliorer les fetches ;
• rechercher les hot partitions.

N’ajoutez pas automatiquement davantage de consumers.

Identifiez d’abord le véritable goulot d’étranglement.

---

13. Éviter les Consumer Rebalances fréquents

Un rebalance interrompt temporairement le traitement normal des partitions.

Les rebalances fréquents peuvent être causés par :

• des traitements trop longs ;
• des consumers instables ;
• des poll intervals inadaptés ;
• des interruptions réseau ;
• des déploiements fréquents ;
• des crashes applicatifs.

Un consumer group sain ne devrait pas être continuellement en rebalance pendant son fonctionnement normal.

---

14. Throughput vs Latency : comprendre le compromis

Il n’existe pas de configuration Kafka unique permettant simultanément d’obtenir le throughput maximal, la latence minimale et la durabilité maximale.

Pour un throughput élevé

On peut privilégier :

Batches plus importants
Compression
Davantage de parallélisme
Fetches plus importants

Pour une faible latence

On peut privilégier :

linger.ms plus faible
Batches plus petits
Traitement immédiat
Fetch wait contrôlé

Pour une forte durabilité

On peut privilégier :

acks=all
Réplication
Idempotence
Configuration ISR appropriée

L’optimisation Kafka représente donc un compromis métier et technique.

---

15. Métriques Kafka à surveiller

Optimiser Kafka sans monitoring revient à travailler à l’aveugle.

Producer Metrics

record-send-rate
record-error-rate
request-latency-avg
request-latency-max
batch-size-avg
compression-rate-avg
buffer-available-bytes

Consumer Metrics

records-consumed-rate
records-lag-max
fetch-rate
fetch-latency-avg
bytes-consumed-rate

Broker Metrics

BytesInPerSec
BytesOutPerSec
MessagesInPerSec
UnderReplicatedPartitions
RequestQueueSize
NetworkProcessorAvgIdlePercent
RequestHandlerAvgIdlePercent

Surveillez également :

CPU
Mémoire
Disk I/O
Espace disque
Réseau
JVM GC

Des outils comme Prometheus et Grafana peuvent fournir des dashboards adaptés au monitoring Kafka.

---

16. Exemple d’optimisation Kafka

Considérons une plateforme e-commerce traitant des événements de commandes.

Configuration initiale :

batch.size=16384
linger.ms=0
compression.type=none
acks=all

Le système présente un trafic réseau important et de nombreuses petites requêtes.

Une configuration de benchmark pourrait être :

batch.size=65536
linger.ms=10
compression.type=lz4
acks=all
enable.idempotence=true

Comparez ensuite :

Avant optimisation
-------------------
Messages/sec
MB/sec
Latence moyenne
Latence p95
Latence p99
CPU
Utilisation réseau

Après optimisation
-------------------
Messages/sec
MB/sec
Latence moyenne
Latence p95
Latence p99
CPU
Utilisation réseau

Conservez la modification uniquement si les mesures démontrent une amélioration correspondant réellement aux objectifs de l’application.

---

17. Erreurs fréquentes lors de l’optimisation Kafka

Erreur 1 : augmenter tous les paramètres

Une valeur plus élevée n’est pas automatiquement synonyme de meilleures performances.

Erreur 2 : créer trop de partitions

Les partitions apportent du parallélisme mais consomment également des ressources.

Erreur 3 : ignorer le Consumer Lag

Des producers très rapides ne servent à rien si les consumers prennent continuellement du retard.

Erreur 4 : optimiser uniquement Kafka

Le véritable problème peut se trouver dans :

Base de données
API REST
Microservice
Réseau
Stockage
Logique métier

Erreur 5 : utiliser des messages énormes

Kafka est une plateforme d’event streaming, pas un système de stockage de fichiers.

Erreur 6 : sacrifier la fiabilité pour améliorer un benchmark

Le nombre maximal de messages par seconde n’est pas nécessairement l’objectif principal d’un système de production.

Erreur 7 : optimiser sans benchmark

Mesurez toujours les performances avant et après chaque modification.

---

18. Checklist d’optimisation Kafka

Avant de considérer votre environnement comme optimisé, vérifiez que :

• le batching producer a été testé ;
• linger.ms correspond aux exigences de latence ;
• la compression a été benchmarkée ;
• acks correspond aux exigences de durabilité ;
• l’idempotence a été évaluée ;
• les partitions sont correctement distribuées ;
• le nombre de partitions permet le parallélisme nécessaire ;
• le consumer lag est surveillé ;
• les consumers traitent efficacement les événements ;
• les rebalances sont maîtrisés ;
• le CPU des brokers reste acceptable ;
• la latence disque est correcte ;
• le réseau dispose d’une capacité suffisante ;
• la réplication est saine ;
• les under-replicated partitions sont surveillées ;
• la taille des messages est maîtrisée ;
• les métriques JVM et OS sont monitorées ;
• les tests reproduisent un trafic proche de la production.

---

Résumé de l’optimisation des performances Kafka

Une stratégie Kafka efficace doit optimiser l’ensemble du pipeline :

Producer
   ↓
Batch + Compression
   ↓
Partitions
   ↓
Kafka Brokers
   ↓
Disque + Réseau + Réplication
   ↓
Consumer Group
   ↓
Traitement parallèle

Pour les producers, concentrez-vous sur :

batch.size + linger.ms + compression.type + acks + buffer.memory

Pour les consumers :

fetch.min.bytes + fetch.max.wait.ms + max.poll.records + temps de traitement + consumer lag

Pour les brokers :

disque + réseau + partitions + réplication + threads + page cache

La règle essentielle reste :

N’optimisez pas Kafka à partir d’hypothèses. Mesurez votre workload, identifiez le goulot d’étranglement, modifiez un élément à la fois et comparez les résultats.

Une configuration idéale pour une plateforme de paiement à très faible latence peut être totalement inadaptée à une plateforme analytique orientée haut débit.

---

Articles recommandés

Microservices Event-Driven avec Kafka et Spring Boot

Découvrez comment Kafka permet une communication asynchrone entre les microservices Spring Boot et contribue à réduire le couplage entre les services.

Kafka Consumer Groups expliqués

Comprenez le fonctionnement des consumer groups, partitions, offsets, rebalancing et du traitement parallèle avec Apache Kafka.

Spring Boot Microservices expliqués

Découvrez les principaux composants et modèles architecturaux utilisés pour développer des microservices avec Spring Boot.

Kafka Event Streaming

Découvrez comment Kafka permet de construire des architectures d’event streaming évolutives pour les applications d’entreprise.

---

Conclusion

Apache Kafka est conçu pour offrir d’excellentes performances, mais les workloads de production nécessitent une optimisation adaptée.

La meilleure stratégie n’est pas de rechercher une configuration Kafka « parfaite ».

Utilisez plutôt une approche continue :

Mesurer → Optimiser → Benchmarker → Monitorer → Répéter

En équilibrant le batching producer, le parallélisme consumer, les ressources broker, les partitions, la compression et la durabilité, Kafka peut supporter des architectures event-driven hautement évolutives tout en maintenant une latence et une fiabilité prévisibles.

Avant de déployer des modifications en production, réalisez toujours des tests avec des tailles de messages, volumes de trafic, nombres de partitions et traitements downstream réalistes.

📢 Besoin d’aide pour Java, workflows ou backend?

J’aide les équipes à concevoir des applications scalables, performantes et prêtes pour la production.

Services:

• Développement Java & Spring Boot
• Implémentation workflows (Camunda, Flowable – BPMN, DMN)
• Intégrations API & microservices
• ECM & gestion documentaire (Alfresco)
• Optimisation performance & résolution incidents

🔗 https://shikhanirankari.blogspot.com/p/professional-services.html

📩 Email: ishikhanirankari@gmail.com | info@realtechnologiesindia.com
🌐 https://realtechnologiesindia.com

✔ Disponible pour consultation rapide
✔ Réponse sous 24 heures

🎥 Learn IT with Shikha on YouTube

Prefer learning through videos? Watch practical tutorials on Kafka, Camunda, Alfresco, Java, Spring Boot, Microservices and Enterprise Architecture.

▶ Subscribe to Learn IT with Shikha on YouTube