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.
# Bonnes pratiques relatives à Amazon SQS
Amazon SQS gère et traite les files d'attente de messages, permettant aux différentes parties d'une application d'échanger des messages de manière fiable et à grande échelle. Cette rubrique décrit les meilleures pratiques opérationnelles clés, notamment l'utilisation de longs sondages pour réduire le nombre de réponses vides, la mise en place de files d'attente contenant des lettres mortes pour gérer les erreurs de traitement et l'optimisation des autorisations de file d'attente pour des raisons de sécurité.
****Rubriques****
+ [Gestion des erreurs et messages problématiques](best-practices-error-handling.md)
+ [Déduplication et regroupement des messages](best-practices-message-deduplication.md)
+ [Traitement des messages et chronométrage](best-practices-message-processing.md)
# Gestion des erreurs et messages problématiques sur Amazon SQS
Cette rubrique fournit des instructions détaillées sur la gestion et l'atténuation des erreurs dans Amazon SQS, notamment les techniques de gestion des erreurs de demande, de capture des messages problématiques et de configuration de la conservation des files d'attente de lettres mortes afin de garantir la fiabilité des messages.
****Rubriques****
+ [Gestion des erreurs de demande dans Amazon SQS](handling-request-errors.md)
+ [Capture des messages problématiques dans Amazon SQS](capturing-problematic-messages.md)
+ [Configuration de la conservation des files d'attente de lettres mortes dans Amazon SQS](setting-up-dead-letter-queue-retention.md)
# Gestion des erreurs de demande dans Amazon SQS
Pour gérer les erreurs de demande, utilisez l'une des stratégies suivantes :
+ Si vous utilisez un AWS SDK, vous disposez déjà d'une logique de *réessai et d'annulation* automatiques. Pour plus d'informations, consultez [Error Retries and Exponential Backoff in AWS(Tentatives sur l'erreur et backoff exponentiel))](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) dans *Référence générale d'Amazon Web Services*.
+ Si vous n'utilisez pas les fonctionnalités du AWS SDK pour réessayer et annuler, attendez une pause (par exemple, 200 ms) avant de réessayer l'[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)action après n'avoir reçu aucun message, un délai d'expiration ou un message d'erreur d'Amazon SQS. Pour permettre une utilisation ultérieure de `ReceiveMessage` qui donne les mêmes résultats, patientez plus longtemps (par exemple, 400 ms).
# Capture des messages problématiques dans Amazon SQS
Pour capturer tous les messages qui ne peuvent pas être traités et pour collecter des CloudWatch statistiques précises, configurez une file d'attente de [lettres mortes](sqs-dead-letter-queues.md).
+ La stratégie de redirection redirige les messages vers une file d'attente de lettres mortes lorsque la file d'attente source ne parvient pas à traiter un message après un nombre de tentatives spécifique.
+ L'utilisation d'une file d'attente de lettres mortes limite le nombre de messages et réduit la possibilité d'être exposé à des messages *de type « poison pill »* (messages reçus mais ne pouvant pas être traités).
+ L'inclusion d'un message de pilule empoisonnée dans une file d'attente peut fausser la [`ApproximateAgeOfOldestMessage`](sqs-available-cloudwatch-metrics.md) CloudWatch métrique en indiquant un âge incorrect au message de pilule empoisonnée. La configuration d'une file d'attente de lettres mortes contribue à éviter les fausses alarmes lors de l'utilisation de cette métrique.
# Configuration de la conservation des files d'attente de lettres mortes dans Amazon SQS
Pour les files d'attente standard, l'expiration d'un message est toujours basée sur son horodatage de mise en file d'attente d'origine. Lorsqu'un message est déplacé vers une file d'attente de lettres mortes, l'horodatage de la mise en file d'attente reste inchangé. La métrique `ApproximateAgeOfOldestMessage` indique à quel moment le message a été placé dans la file d'attente de lettres mortes, et *non* à quel moment le message a été initialement envoyé. Supposons, par exemple, qu'un message passe 1 journée dans la file d'attente d'origine avant d'être déplacé vers une file d'attente de lettres mortes. Si la période de conservation de la file d'attente de lettres mortes est de 4 jours, le message est supprimé de la file d'attente de lettres mortes au bout de 3 jours et le paramètre `ApproximateAgeOfOldestMessage` est défini sur 3 jours. Il est donc recommandé de toujours définir la période de rétention d'une file d'attente de lettres mortes de manière à ce qu'elle soit plus longue que la période de rétention de la file d'attente d'origine.
Pour les files d'attente FIFO, l'horodatage de la mise en file d'attente est réinitialisé lorsque le message est déplacé vers une file d'attente de lettres mortes. La métrique `ApproximateAgeOfOldestMessage` indique à quel moment le message a été placé dans la file d'attente de lettres mortes. Dans le même exemple ci-dessus, le message est supprimé de la file d'attente de lettres mortes au bout de 4 jours et le paramètre `ApproximateAgeOfOldestMessage` est défini sur 4 jours.
# Déduplication et regroupement des messages Amazon SQS
Cette rubrique présente les meilleures pratiques pour garantir un traitement cohérent des messages dans Amazon SQS. Il explique comment utiliser :
+ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html#API_SendMessage_RequestSyntax](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html#API_SendMessage_RequestSyntax)pour empêcher la duplication de messages dans les files d'attente FIFO.
+ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)pour gérer l'ordre des messages au sein de groupes de messages distincts.
****Rubriques****
+ [Éviter le traitement incohérent des messages dans Amazon SQS](avoiding-inconsistent-message-processing.md)
+ [Utilisation de l'ID de déduplication du message](using-messagededuplicationid-property.md)
+ [Utilisation de l'ID de groupe de messagerie](using-messagegroupid-property.md)
+ [Utilisation de l'ID de tentative de demande de réception](using-receiverequestattemptid-request-parameter.md)
# Éviter le traitement incohérent des messages dans Amazon SQS
Amazon SQS est un système distribué. Il est donc possible qu'un consommateur ne reçoive pas de message, même lorsque Amazon SQS marque le message comme remis lors d'un retour réussi à partir d'un appel de méthode d'API [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html). Dans ce cas, Amazon SQS enregistre le message tel qu'il a été remis au moins une fois, bien que le consommateur ne l'ait jamais reçu. Étant donné qu'aucune tentative supplémentaire de remise de messages n'est effectuée dans ces conditions, nous ne recommandons pas de définir le nombre maximal de réceptions sur 1 pour une [file d'attente de lettres mortes](sqs-dead-letter-queues.md).
# Utilisation de l'ID de déduplication des messages dans Amazon SQS
[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)est un jeton utilisé uniquement dans les files d'attente FIFO Amazon SQS pour empêcher la livraison de messages en double. Il garantit que dans une fenêtre de déduplication de 5 minutes, une seule instance d'un message portant le même ID de déduplication est traitée et délivrée.
Si Amazon SQS a déjà accepté un message avec un ID de déduplication spécifique, tous les messages suivants portant le même identifiant feront l'objet d'un accusé de réception mais ne seront pas remis aux consommateurs.
**Note**
Amazon SQS continue de suivre l'ID de déduplication même après réception et suppression du message.
**Topics**
+ [Quand fournir un ID de déduplication des messages dans Amazon SQS](providing-message-deduplication-id.md)
+ [Activation de la déduplication pour un système producteur/consommateur unique dans Amazon SQS](single-producer-single-consumer.md)
+ [Scénarios de reprise en cas de panne dans Amazon SQS](designing-for-outage-recovery-scenarios.md)
+ [Configuration des délais de visibilité dans Amazon SQS](working-with-visibility-timeouts.md)
# Quand fournir un ID de déduplication des messages dans Amazon SQS
Le producteur doit spécifier un ID de déduplication des messages dans les scénarios suivants :
+ Lors de l'envoi de corps de message identiques, ils doivent être traités comme uniques.
+ Lorsque vous envoyez des messages ayant le même contenu mais des attributs différents, assurez-vous que chaque message est traité séparément.
+ Lorsque vous envoyez des messages avec un contenu différent (par exemple, un compteur de nouvelles tentatives dans le corps du message) mais que vous demandez à Amazon SQS de les reconnaître comme des doublons.
# Activation de la déduplication pour un système producteur/consommateur unique dans Amazon SQS
Si vous avez un seul producteur et un seul consommateur, et que les messages sont uniques car ils incluent un ID de message spécifique à l'application dans le corps du message, suivez les bonnes pratiques suivantes :
+ Activez la déduplication basée sur le contenu pour la file d'attente (chacun de vos messages a un corps unique). Le producteur peut ignorer l'ID de déduplication du message.
+ Lorsque la déduplication basée sur le contenu est activée pour une file d'attente Amazon SQS FIFO et qu'un message est envoyé avec un ID de déduplication, l'ID de déduplication remplace l'ID de déduplication basé sur le contenu [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)généré.
+ Même si le consommateur n'est pas tenu de fournir un ID de tentative de demande de réception pour chaque demande, il vaut mieux le faire, car cela permet aux séquences échec-réessayer de s'exécuter plus rapidement.
+ Vous pouvez réessayer d'envoyer ou de recevoir des demandes, car elles n'interfèrent pas avec l'ordre des messages dans les files d'attente FIFO.
# Scénarios de reprise en cas de panne dans Amazon SQS
Le processus de déduplication dans les files d'attente FIFO est prioritaire. Lors de la conception de votre application, veillez à ce que le producteur et le consommateur puissent se rétablir après une panne du client ou du réseau sans créer de doublons ni d'erreurs de traitement.
Considérations relatives aux producteurs
+ Amazon SQS applique une fenêtre de déduplication de 5 minutes.
+ Si un producteur réessaie une [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)demande après 5 minutes, Amazon SQS la traite comme un nouveau message, ce qui peut créer des doublons.
Considérations relatives aux consommateurs
+ Si un client ne traite pas un message avant l'expiration du délai de visibilité, un autre client peut le recevoir et le traiter, ce qui entraîne un double traitement.
+ Ajustez le délai de visibilité en fonction du temps de traitement de votre demande.
+ Utilisez l'[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html)API pour prolonger le délai d'attente pendant qu'un message est toujours en cours de traitement.
+ Si le traitement d'un message échoue à plusieurs reprises, acheminez-le vers une [file d'attente de lettres mortes (DLQ)](sqs-dead-letter-queues.md) au lieu de le retraiter indéfiniment.
+ Le producteur doit connaître l'intervalle de déduplication de la file d'attente. Amazon SQS a un intervalle de déduplication de 5 minutes. De nouvelles tentatives de demandes de `SendMessage` après expiration du délai de déduplication peuvent introduire des messages en double dans la file d'attente. Par exemple, un appareil mobile dans une voiture envoie des messages dont l'ordre est important. Si la voiture perd la connectivité cellulaire pendant un certain temps avant de recevoir une confirmation, une nouvelle tentative de la demande après la récupération de la connectivité cellulaire peut créer un doublon.
+ Le consommateur doit disposer d'un délai de visibilité réduisant le risque de ne pas pouvoir traiter des messages avant l'expiration de ce délai. Vous pouvez étendre le délai de visibilité pendant que les messages sont en cours de traitement en appelant l'action `ChangeMessageVisibility`. Toutefois, si le délai de visibilité expire, un autre consommateur peut immédiatement commencer à traiter les messages, un message étant alors traité plusieurs fois. Pour éviter ce scénario, configurez une [file d'attente de lettres mortes](sqs-dead-letter-queues.md).
# Configuration des délais de visibilité dans Amazon SQS
Pour garantir un traitement fiable des messages, définissez le délai de visibilité pour qu'il soit supérieur au délai de lecture du AWS SDK. Cela s'applique lorsque l'[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)API est utilisée à la fois pour des interrogations courtes et des interrogations longues. Un délai de visibilité plus long empêche les messages d'être mis à la disposition des autres consommateurs avant que la demande initiale ne soit terminée, ce qui réduit le risque de double traitement.
# Utilisation de l'ID de groupe de messages avec les files d'attente FIFO Amazon SQS
Dans les files d'attente FIFO (First-In-First-Out), se [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)trouve un attribut qui organise les messages en groupes distincts. Les messages d'un même groupe de messages sont toujours traités un par un, dans un ordre strict, afin que deux messages du même groupe ne soient pas traités simultanément. Dans les files d'attente standard, l'utilisation `MessageGroupId` permet d'établir des [files d'attente équitables](sqs-fair-queues.md). Si un ordre strict est requis, utilisez une file d'attente FIFO.
**Topics**
+ [Entrelacement de plusieurs groupes de messages ordonnés dans Amazon SQS](interleaving-multiple-ordered-message-groups.md)
+ [Empêcher le traitement dupliqué dans un système comportant plusieurs producteurs/consommateurs dans Amazon SQS](avoding-processing-duplicates-in-multiple-producer-consumer-system.md)
+ [Évitez les gros arriérés de messages avec le même ID de groupe de messages dans Amazon SQS](avoid-backlog-with-the-same-message-group-id.md)
+ [Évitez de réutiliser le même ID de groupe de messages avec les files d'attente virtuelles dans Amazon SQS](avoiding-reusing-message-group-id-with-virtual-queues.md)
# Entrelacement de plusieurs groupes de messages ordonnés dans Amazon SQS
Pour entrelacer plusieurs groupes de messages ordonnés dans une seule file d'attente FIFO, attribuez un [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)à chaque groupe (par exemple, des données de session pour différents utilisateurs). Cela permet à plusieurs consommateurs de lire simultanément des informations dans la file d'attente tout en garantissant que les messages d'un même groupe sont traités dans l'ordre.
Lorsqu'un message contenant un message spécifique `MessageGroupId` est en cours de traitement et qu'il est invisible, aucun autre consommateur ne peut traiter les messages du même groupe tant que le délai de visibilité n'est pas expiré ou que le message n'est pas supprimé.
# Empêcher le traitement dupliqué dans un système comportant plusieurs producteurs/consommateurs dans Amazon SQS
Dans un système à haut débit et à faible latence où l'ordre des messages n'est pas une priorité, les producteurs peuvent attribuer une valeur unique [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)à chaque message. Cela garantit que les files d'attente FIFO Amazon SQS éliminent les doublons, même dans une configuration multi-producteurs/multi-consommateurs. Bien que cette approche évite les doublons, elle ne garantit pas l'ordre des messages puisque chaque message est traité comme un groupe indépendant.
Dans tout système comportant plusieurs producteurs et consommateurs, il existe toujours un risque de double livraison. Si un client ne parvient pas à traiter un message avant l'expiration du délai de visibilité, Amazon SQS le rend à nouveau disponible, ce qui permet éventuellement à un autre consommateur de le récupérer. Pour atténuer ce problème, assurez-vous que les paramètres d'accusé de réception des messages et de délai de visibilité sont appropriés en fonction du temps de traitement.
# Évitez les gros arriérés de messages avec le même ID de groupe de messages dans Amazon SQS
Les files d'attente FIFO prennent en charge un maximum de 120 000 messages en cours de vol (messages reçus par un consommateur mais pas encore supprimés). Si cette limite est atteinte, Amazon SQS ne renvoie pas d'erreur, mais le traitement peut en être affecté. Vous pouvez demander une augmentation au-delà de cette limite en contactant le [AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/create-service-quota-increase.html).
Les files d'attente FIFO analysent les 120 000 premiers messages pour déterminer les groupes de messages disponibles. Si un important arriéré s'accumule dans un seul groupe de messages, les messages envoyés ultérieurement par d'autres groupes resteront bloqués jusqu'à ce que le backlog soit traité.
**Note**
Un arriéré de messages peut se produire lorsqu'un client échoue à plusieurs reprises à traiter un message. Cela peut être dû à des problèmes liés au contenu des messages ou à des défaillances du côté du consommateur. Pour éviter les retards dans le traitement des messages, configurez une [file d'attente de lettres mortes](sqs-dead-letter-queues.md) pour déplacer les messages non traités après plusieurs tentatives infructueuses. Cela garantit que les autres messages du même groupe de messages peuvent être traités, évitant ainsi les engorgements du système.
# Évitez de réutiliser le même ID de groupe de messages avec les files d'attente virtuelles dans Amazon SQS
Lorsque vous utilisez des files d'attente virtuelles avec une file d'hôtes partagée, évitez de les réutiliser [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)dans différentes files d'attente virtuelles. Si plusieurs files d'attente virtuelles partagent la même file d'attente d'hôtes et contiennent des messages identiques`MessageGroupId`, ces messages peuvent se bloquer mutuellement, empêchant ainsi un traitement efficace. Pour garantir un traitement fluide des messages, attribuez des `MessageGroupId` valeurs uniques aux messages dans différentes files d'attente virtuelles.
# Utilisation de l'ID de tentative de demande de réception Amazon SQS
L'ID de tentative de demande de réception est un jeton unique utilisé pour dédupliquer les [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)appels dans Amazon SQS. Lors d'une panne réseau ou d'un problème de connectivité entre votre application et Amazon SQS, il est recommandé de :
+ Fournissez un identifiant de tentative de demande de réception lorsque vous passez un `ReceiveMessage` appel.
+ Réessayez en utilisant le même ID de tentative de demande de réception si l'opération échoue.
# 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.