Conséquences du maintien de linger.ms à 0
Nous utilisons kafka 0.10.2.1. La documentation spécifie qu'un tampon est disponible pour envoyer même s'il n'est pas plein-
Par défaut, un tampon est disponible pour envoyer immédiatement même s'il y a de l'espace inutilisé supplémentaire dans le tampon. Cependant, si vous souhaitez réduire le nombre de demandes, vous pouvez définir linger.ms à quelque chose de supérieur à 0.
Cependant, il indique également que le producteur tentera de regrouper les demandes même si le temps de latence est défini sur 0 ms.
Notez que les enregistrements qui arrivent proches les uns des autres dans le temps seront généralement regroupés, même avec linger.ms = 0, donc sous forte charge, le traitement par lots se produira quelle que soit la configuration de la persistance; cependant, la définition de quelque chose de plus grand que 0 peut entraîner des demandes moins nombreuses et plus efficaces lorsqu'elles ne sont pas sous une charge maximale au prix d'une petite latence.
Intuitivement, il semble que tout type de traitement par lots nécessiterait un certain temps de latence, et la seule façon d'atteindre un temps de latence de 0 serait de synchroniser l'appel du courtier. De toute évidence, le maintien du temps de latence à 0 ne semble pas nuire aux performances autant que le blocage de l'appel d'envoi, mais semble avoir un impact sur les performances. Quelqu'un peut-il clarifier ce que les documents disent ci-dessus?
Les documents disent que même si vous définissez le temps de latence à 0, vous pourriez vous retrouver avec un peu de traitement par lots sous charge, car les enregistrements sont ajoutés pour être envoyés plus rapidement que le thread d'envoi ne peut les distribuer. Ce paramètre est optimisé pour une latence minimale. Si la mesure des performances dont vous vous souciez vraiment est le débit, vous augmenteriez un peu le temps de latence pour regrouper davantage et c'est ce que les documents visent. Pas tellement à voir avec l'envoi synchrone dans ce cas. Informations plus détaillées
Avec linger.ms=0 l'enregistrement est envoyé dès que possible et avec de nombreuses demandes, cela peut affecter les performances. Forcer un peu d'attente en augmentant linger.ms sur une charge modérée/élevée optimisera l'utilisation du lot et augmentera le débit. Cela dépend aussi de la taille de l'enregistrement, plus grande est la taille, moins elle peut tenir dans le lot (batch.size la valeur par défaut est 16 Ko).
Fondamentalement, c'est un compromis entre le nombre de nombre de demandes et le débit et cela dépend vraiment de votre scénario, mais l'envoi immédiat ne tire pas pleinement parti du traitement par lots et la compression (si activé) et je suggère d'exécuter des métriques avec différentes valeurs de linger.ms comme 0/5/10/50/200
En général, je proposerai de définir linger.ms > 0
Références: