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.
# Traitement et chronométrage des messages Amazon SQS
Cette rubrique fournit des conseils complets sur l'optimisation de la vitesse et de l'efficacité du traitement des messages dans Amazon SQS, notamment des stratégies pour traiter les messages en temps opportun, sélectionner le meilleur mode d'interrogation et configurer des interrogations longues pour améliorer les performances.
****Rubriques****
+ [Traitement des messages en temps opportun dans Amazon SQS](best-practices-processing-messages-timely-manner.md)
+ [Configuration d'un long sondage dans Amazon SQS](best-practices-setting-up-long-polling.md)
+ [Utilisation du mode d'interrogation approprié dans Amazon SQS](best-practices-using-appropriate-polling-mode.md)
# Traitement des messages en temps opportun dans Amazon SQS
Le délai de visibilité défini dépend de la durée nécessaire à votre application pour traiter et supprimer un message. Par exemple, si votre application a besoin de 10 secondes pour traiter un message et que vous définissez un délai de visibilité de 15 minutes, vous devez attendre relativement longtemps pour tenter de retraiter le message si la dernière tentative de traitement échoue. En revanche, si votre application a besoin de 10 secondes pour traiter un message, mais que vous définissez un délai de visibilité de seulement 2 secondes, un message dupliqué est reçu par un autre consommateur alors que le consommateur d'origine est toujours en train de travailler sur le message.
Pour vérifier qu'il y a suffisamment de temps pour traiter les messages, utilisez l'une des stratégies suivantes :
+ Si vous savez (ou si vous pouvez raisonnablement estimer) combien de temps est nécessaire pour traiter un message, rallongez le *délai de visibilité* de sorte qu'il corresponde à la durée maximale requise pour traiter et supprimer le message. Pour plus d'informations, consultez [Configuration du délai de visibilité](sqs-visibility-timeout.md#configuring-visibility-timeout).
+ Si vous ne savez pas combien de temps il faut pour traiter un message, créez une *pulsation* pour votre processus de consommateur : spécifiez le délai de visibilité initial (par exemple, 2 minutes) puis, tant que votre client travaille sur le message, continuez à prolonger le délai de visibilité de 2 minutes, toutes les minutes.
**Important**
Le délai maximal de visibilité est de 12 heures à compter de l'heure où Amazon SQS reçoit la demande `ReceiveMessage`. L'extension du délai d'attente de visibilité ne réinitialise pas le maximum de 12 heures.
En outre, il se peut que vous ne puissiez pas régler le délai d'expiration d'un message individuel sur 12 heures (par exemple, 43 200 secondes) puisque la demande `ReceiveMessage` déclenche le temporisateur. Par exemple, si vous recevez un message et que vous définissez immédiatement le maximum de 12 heures en envoyant un appel `ChangeMessageVisibility` avec `VisibilityTimeout` défini sur une durée égale à 43 200 secondes, il échouera probablement. En revanche, l'utilisation d'une valeur de 43 195 secondes fonctionnera, à moins qu'il n'y ait un délai important entre la demande du message via `ReceiveMessage` et la mise à jour du délai de visibilité. Si votre client a besoin de plus de 12 heures, envisagez d'utiliser Step Functions.
# Configuration d'un long sondage dans Amazon SQS
Lorsque le temps d'attente pour l'action de l'API `[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)` est supérieur à 0, une *recherche prolongée* est activée. Le temps d'attente maximal pour la recherche prolongée est de 20 secondes. Les longs sondages permettent de réduire le coût d'utilisation d'Amazon SQS en réduisant le nombre de réponses vides (lorsqu'aucun message n'est disponible pour une `ReceiveMessage` demande) et de fausses réponses vides (lorsque les messages sont disponibles mais ne sont pas inclus dans une réponse). Pour de plus amples informations, veuillez consulter [Recherches courtes et longues sur Amazon SQS](sqs-short-and-long-polling.md).
Pour garantir un traitement optimal des messages, utilisez les stratégies suivantes :
+ Dans la plupart des cas, vous pouvez définir le délai d'attente `ReceiveMessage` à 20 secondes. Si un délai de 20 secondes est trop long pour votre application, définissez un délai d'attente `ReceiveMessage` plus court (1 seconde au minimum). Si vous n'utilisez pas de AWS SDK pour accéder à Amazon SQS, ou si vous configurez AWS un SDK pour réduire le temps d'attente, vous devrez peut-être modifier votre client Amazon SQS pour autoriser des demandes plus longues ou utiliser un temps d'attente plus court pour les longs sondages.
+ Si vous implémentez l'attente active de longue durée pour plusieurs files d'attente, utilisez un thread pour chacune d'elles plutôt qu'un seul thread pour toutes les files d'attente. L'utilisation d'un seul thread pour chaque file d'attente permet à votre application de traiter les messages de chacune des files d'attente dès qu'ils sont disponibles. En revanche, en utilisant un seul thread pour l'interrogation de plusieurs files d'attente peut mettre votre application dans l'incapacité de traiter les messages disponibles dans d'autres files d'attente lorsque l'application attend (pendant une durée pouvant atteindre 20 secondes) la file d'attente qui ne comporte aucun message.
**Important**
Pour éviter les erreurs HTTP, assurez-vous que le temps d'attente de réponse HTTP pour les demandes `ReceiveMessage` est plus long que le paramètre `WaitTimeSeconds`. Pour de plus amples informations, veuillez consulter [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html).
# Utilisation du mode d'interrogation approprié dans Amazon SQS
+ La recherche prolongée vous permet de consommer des messages de votre file d'attente Amazon SQS dès qu'ils sont disponibles.
+ Pour réduire le coût d'utilisation d'Amazon SQS et le nombre de réceptions vides dans une file d'attente vide (réponses à l'action `ReceiveMessage` qui ne renvoient aucun message), activez la recherche prolongée. Pour plus d'informations, consultez [Recherche prolongée Amazon SQS](sqs-short-and-long-polling.md).
+ Pour accroître l'efficacité lors de l'attente active de plusieurs threads avec plusieurs réceptions, diminuez le nombre de threads.
+ Dans la plupart des cas, l'attente active de longue durée est préférable à celle de courte durée.
+ L'attente active de courte durée retourne des réponses immédiatement, même si la file d'attente Amazon SQS interrogée est vide.
+ Pour satisfaire aux exigences d'une application qui attend des réponses immédiates à la demande `ReceiveMessage`, utilisez l'attente active de courte durée.
+ L'attente active de courte durée coûte le même prix que l'attente active de longue durée.