Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Optimisez les producteurs de Kinesis Data Streams
Vous pouvez optimiser davantage vos producteurs Amazon Kinesis Data Streams en fonction du comportement spécifique que vous observez. Consultez les rubriques suivantes pour identifier des solutions.
**Topics**
+ [Personnalisation des nouvelles tentatives KPL et du comportement des limites de débit](kinesis-producer-adv-retries-rate-limiting.md)
+ [Appliquer les meilleures pratiques à l'agrégation KPL](kinesis-producer-adv-aggregation.md)
# Personnalisation des nouvelles tentatives KPL et du comportement des limites de débit
Lorsque vous ajoutez des enregistrements utilisateur Amazon Kinesis Producer Library (KPL) à l'aide de l'`addUserRecord()`opération KPL, un enregistrement reçoit un horodatage et est ajouté à une mémoire tampon avec une date limite définie par le paramètre de configuration. `RecordMaxBufferedTime` Cette stamp/deadline combinaison de temps définit la priorité de la mémoire tampon. Les enregistrements sont vidés de la mémoire tampon selon les critères suivants :
+ Priorité tampon
+ Configuration du regroupement
+ Configuration de la collecte
Les paramètres de configuration du regroupement et de la collecte qui influencent le comportement du tampon sont les suivants :
+ `AggregationMaxCount`
+ `AggregationMaxSize`
+ `CollectionMaxCount`
+ `CollectionMaxSize`
Les enregistrements vidés sont ensuite envoyés à votre flux de données Kinesis sous forme d'enregistrements Amazon Kinesis Data Streams à l'aide d'un appel à l'opération d'API Kinesis Data Streams `PutRecords`. L'opération `PutRecords` envoie des demandes à votre flux qui échouent parfois entièrement ou partiellement. Les enregistrements qui échouent sont automatiquement renvoyés au tampon KPL. Le nouveau délai est défini sur la base du minimum des deux valeurs suivantes :
+ La moitié de la configuration `RecordMaxBufferedTime` actuelle
+ La time-to-live valeur de l'enregistrement
Cette stratégie permet d'inclure les enregistrements utilisateur KPL réessayés dans les appels d'API Kinesis Data Streams suivants, afin d'améliorer le débit et de réduire la complexité tout en renforçant la valeur de l'enregistrement Kinesis Data Streams. time-to-live Il n'y a aucun algorithme d'interruption, ce qui rend cette stratégie de nouvelle tentative relativement brutale. Le spam provoqué par des tentatives excessives est empêché par la limitation de vitesse, qui est présentée à la section suivante.
## Limitation du débit
La KPL comprend une fonctionnalité de limitation de vitesse, qui limite le débit par partition envoyé par une seule application producteur. La limitation de vitesse est implémentée à l'aide d'un algorithme de compartiment à jeton, avec des compartiments distincts pour les enregistrements Kinesis Data Streams et les octets. Chaque écriture réussie dans un flux de données Kinesis ajoute un jeton (ou plusieurs jetons) à chaque compartiment, jusqu'à un certain seuil. Ce seuil est configurable, mais est défini par défaut sur une valeur 50 % supérieure au nombre limite de partitions réel afin d'autoriser la saturation de partition par une seule application producteur.
Vous pouvez réduire ce nombre limite pour diminuer le spam dû aux tentatives excessives. Toutefois, la bonne pratique consiste, pour chaque application producteur, à effectuer des tentatives brutales pour atteindre un débit maximal et à traiter toute limitation obtenue comme excessive en étendant la capacité du flux et en mettant en œuvre une stratégie de clé de partition appropriée.
# Appliquer les meilleures pratiques à l'agrégation KPL
Bien que le schéma de numérotation des enregistrements Amazon Kinesis Data Streams obtenus reste le même, l'agrégation entraîne l'indexation des enregistrements utilisateur Amazon Kinesis Producer Library (KPL) contenus dans un enregistrement Kinesis Data Streams agrégé à partir de 0 (zéro) ; toutefois, tant que vous ne vous fiez pas aux numéros de séquence pour identifier de manière unique vos enregistrements utilisateur KPL, votre code peut l'ignorer, car l'agrégation (de vos enregistrements utilisateur KPL dans un enregistrement Kinesis Data Streams) et désagrégation ultérieure (d'un enregistrement Kinesis Data Streams dans vos enregistrements utilisateur KPL) s'en charge automatiquement pour vous. Cela s'applique que votre consommateur utilise la KCL ou le AWS SDK. Pour utiliser cette fonctionnalité d'agrégation, vous devez intégrer la partie Java du KPL dans votre build si votre client est écrit à l'aide de l'API fournie dans le AWS SDK.
Si vous prévoyez d'utiliser les numéros de séquence comme des identifiants uniques pour vos enregistrements utilisateur KPL, nous vous recommandons d'utiliser les opérations `public int hashCode()` et `public boolean equals(Object obj)` conformes au contrat et fournies dans `Record` et `UserRecord` pour permettre la comparaison de vos enregistrements utilisateur KPL. En outre, si vous souhaitez examiner le numéro de sous-séquence de votre enregistrement utilisateur KPL, vous pouvez le convertir en instance `UserRecord` et extraire son numéro de sous-séquence.
Pour de plus amples informations, veuillez consulter [Mettre en œuvre la désagrégation des consommateurs](kinesis-kpl-consumer-deaggregation.md).