

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Amazon SQS SQS-Nachrichtenverarbeitung und Timing
<a name="best-practices-message-processing"></a>

Dieses Thema bietet umfassende Anleitungen zur Optimierung der Geschwindigkeit und Effizienz der Nachrichtenverarbeitung in Amazon SQS, einschließlich Strategien für die zeitnahe Nachrichtenverarbeitung, die Auswahl des besten Abfragemodus und die Konfiguration langer Abfragen zur Verbesserung der Leistung.

****Topics****
+ [Rechtzeitige Verarbeitung von Nachrichten in Amazon SQS](best-practices-processing-messages-timely-manner.md)
+ [Einrichtung von Long Polling in Amazon SQS](best-practices-setting-up-long-polling.md)
+ [Verwenden des entsprechenden Abfragemodus in Amazon SQS](best-practices-using-appropriate-polling-mode.md)

# Rechtzeitige Verarbeitung von Nachrichten in Amazon SQS
<a name="best-practices-processing-messages-timely-manner"></a>

Die Einstellung der Zeitbeschränkung für die Sichtbarkeit hängt davon ab, wie lange Ihre Anwendung braucht, um eine Nachricht zu verarbeiten und zu löschen. Benötigt Ihre Anwendung beispielsweise 10 Sekunden für die Verarbeitung einer Nachricht und Sie setzen die Zeitbeschränkung für die Sichtbarkeit auf 15 Minuten, müssen Sie relativ lange warten, bis Sie erneut versuchen können, die Nachricht zu verarbeiten, wenn der vorherige Versuch einer Verarbeitung fehlgeschlagen ist. Benötigt Ihre Anwendung alternativ 10 Sekunden für die Verarbeitung einer Nachricht, Sie setzen die Zeitbeschränkung für die Sichtbarkeit jedoch auf nur 2 Sekunden, wird eine duplizierte Nachricht von einem anderen Verbraucher empfangen, während der ursprüngliche Verbraucher die Nachricht noch verarbeitet.

Um sicherzustellen, dass ausreichend Zeit für die Verarbeitung von Nachrichten vorhanden ist, nutzen Sie eine der folgenden Strategien:
+ Wenn Sie wissen (oder annähernd schätzen können), wie lange die Verarbeitung einer Nachricht dauert, erweitern Sie die *Zeitbeschränkung für die Sichtbarkeit* auf die maximale Zeit, die erforderlich ist, um die Nachricht zu verarbeiten und zu löschen. Weitere Informationen finden Sie unter [Konfiguration der Sichtbarkeitszeitbeschränkung](sqs-visibility-timeout.md#configuring-visibility-timeout).
+ Wenn Sie nicht wissen, wie lange die Bearbeitung einer Nachricht dauert, erstellen Sie einen *Heartbeat* für Ihren Kundenprozess: Geben Sie das anfängliche Timeout für die Sichtbarkeit an (z. B. 2 Minuten) und verlängern Sie dann, solange Ihr Kunde noch an der Nachricht arbeitet, die Sichtbarkeitszeitbeschränkung jede Minute um 2 Minuten. 
**Wichtig**  
Die maximale Zeitbeschränkung für die Sichtbarkeit beträgt 12 Stunden ab dem Zeitpunkt, an dem Amazon SQS die `ReceiveMessage`-Anforderung empfängt. Durch die Verlängerung der Sichtbarkeitszeitbeschränkung wird das Maximum von 12 Stunden nicht zurückgesetzt.  
Darüber hinaus können Sie das Timeout für eine einzelne Nachricht möglicherweise nicht auf die vollen 12 Stunden (z. B. 43 200 Sekunden) festlegen, seit die `ReceiveMessage`-Anfrage den Timer initiiert hat. Wenn Sie beispielsweise eine Nachricht erhalten und sofort das Maximum von 12 Stunden festlegen, indem Sie einen `ChangeMessageVisibility`-Aufruf mit einem `VisibilityTimeout` von 43 200 Sekunden senden, schlägt der Vorgang wahrscheinlich fehl. Die Verwendung eines Werts von 43 195 Sekunden funktioniert jedoch, sofern es nicht zu einer erheblichen Verzögerung zwischen dem Anfordern der Nachricht über `ReceiveMessage` und der Aktualisierung der Sichtbarkeitszeitbeschränkung kommt. Wenn Ihr Verbraucher länger als 12 Stunden benötigt, sollten Sie die Verwendung von Step Functions in Betracht ziehen. 

# Einrichtung von Long Polling in Amazon SQS
<a name="best-practices-setting-up-long-polling"></a>

Ist die Wartezeit für die `[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)`-API-Aktion größer als 0, ist eine *lange Abfrage* wirksam. Die maximale Wartezeit für lange Abfragen beträgt 20 Sekunden. Lange Abfragen tragen dazu bei, die Kosten für die Nutzung von Amazon SQS zu senken, indem die Anzahl der leeren Antworten (wenn für eine `ReceiveMessage` Anfrage keine Nachrichten verfügbar sind) und der falschen leeren Antworten (wenn Nachrichten verfügbar sind, aber nicht in einer Antwort enthalten sind) reduziert wird. Weitere Informationen finden Sie unter [Kurz- und Langabfragen in Amazon SQS](sqs-short-and-long-polling.md).

Um eine optimale Nachrichtenverarbeitung sicherzustellen, wenden Sie die folgenden Strategien an:
+ In den meisten Fällen können Sie die `ReceiveMessage`-Wartezeit auf 20 Sekunden setzen. Wenn 20 Sekunden für Ihre Anwendung zu lang ist, legen Sie eine kürzere `ReceiveMessage`-Wartezeit fest (mindestens 1 Sekunde). Wenn Sie kein AWS SDK für den Zugriff auf Amazon SQS verwenden oder wenn Sie ein AWS SDK für eine kürzere Wartezeit konfigurieren, müssen Sie Ihren Amazon SQS SQS-Client möglicherweise ändern, um entweder längere Anfragen zuzulassen oder eine kürzere Wartezeit für lange Abfragen zu verwenden.
+ Wenn Sie Langabfragen für mehrere Warteschlangen implementieren, verwenden Sie einen Thread für jede Warteschlange statt eines einzelnen Threads für alle Warteschlangen. Durch die Verwendung eines einzelnen Threads für jede Warteschlange kann Ihre Anwendung die Nachrichten in jeder der Warteschlangen verarbeiten, sobald diese verfügbar sind, während bei Verwendung eines einzelnen Threads für die Abfrage mehrerer Warteschlangen dazu führen könnte, dass Ihre Anwendung die Nachrichten nicht verarbeiten kann, die in anderen Warteschlangen zur Verfügung stehen, während die Anwendung auf die Warteschlange wartet (bis zu 20 Sekunden), die keine verfügbaren Nachrichten enthält.

**Wichtig**  
Um HTTP-Fehler zu vermeiden, stellen Sie sicher, dass das HTTP-Reaktions-Timeout für `ReceiveMessage`-Anforderungen länger ist als der `WaitTimeSeconds`-Parameter. Weitere Informationen finden Sie unter [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html).

# Verwenden des entsprechenden Abfragemodus in Amazon SQS
<a name="best-practices-using-appropriate-polling-mode"></a>
+ Mit einer Langabfrage können Sie Nachrichten aus Ihrer Amazon-SQS-Warteschlange nutzen, sobald diese verfügbar sind. 
  + Um die Verwendungskosten für Amazon SQS zu senken und die Anzahl der leeren Empfangsvorgänge in einer leeren Warteschlange zu reduzieren, (Antworten auf die `ReceiveMessage`-Aktion, mit der keine Nachrichten zurückgegeben werden), aktivieren Sie die Langabfrage. Weitere Informationen finden Sie unter [Amazon-SQS-Langabfragen](sqs-short-and-long-polling.md).
  + Um die Effizienz beim Abfragen für mehrere Threads mit mehreren Empfangsvorgängen zu steigern, verringern Sie die Anzahl der Threads.
  + Langabfragen sind Kurzabfragen in den meisten Fällen vorzuziehen.
+ Eine Kurzabfrage gibt Antworten sofort zurück, auch wenn die abgefragte Amazon-SQS-Warteschlange leer ist. 
  + Um die Anforderungen einer Anwendung zu erfüllen, die sofortige Antworten auf die Abfrage `ReceiveMessage` erwartet, verwenden Sie die Kurzabfrage.
  + Die Kurzabfrage wird mit denselben Kosten in Rechnung gestellt wie die Langabfrage.