Best Practices für die Anfragelatenz und Fehlerbehandlung

Auf dieser Seite werden Best Practices zum Optimieren der Anfragelatenz und zum Umgang mit Fehlern in der Cloud Healthcare API beschrieben. Implementieren Sie diese Praktiken bei der Planung und dem Design Ihrer Systemarchitektur.

Google bietet ein Service Level Agreement (SLA), in dem die erwartete Verfügbarkeit des Cloud Healthcare API-Dienstes und wie Clients mit Fehlern umgehen können. Weitere Informationen finden Sie im Service Level Agreement (SLA) für Cloud Healthcare.

Wiederholungslogik und Zeitüberschreitungen implementieren

Implementieren Sie eine geeignete Wiederholungslogik und Zeitüberschreitungen, um Verzögerungen und Fehler zu beheben, die durch fehlgeschlagene Anfragen verursacht werden. Lassen Sie beim Festlegen des Zeitlimits Zeit, um Folgendes zu tun:

  • Lassen Sie die Cloud Healthcare API die Anfrage verarbeiten.
  • Ermitteln Sie, ob der Fehler vom Dienst oder vom Client stammt.

Bei einigen Fehlern können Sie einen Wiederholungsversuch starten, bei anderen ist dies nicht möglich und sie bleiben auch nach mehreren Versuchen bestehen. Wenn die Anfragedaten beispielsweise falsch formatiert sind, antwortet der Server mit dem Statuscode 400 Bad Request. Der Antrag kann erst erfolgreich abgeschlossen werden, wenn Sie die Daten korrigiert haben.

Für diese Situationen müssen Sie Endfehlerstatus planen.

Weitere Informationen zur Wiederholungslogik und zu Zeitüberschreitungen finden Sie unter Fehlgeschlagene Anfragen wiederholen.

Fehler auf mehreren Ebenen verarbeiten

Wenn Middleware mit der Cloud Healthcare API interagiert, implementieren Sie die Wiederholungslogik. und Zeitüberschreitungen im Client und in der Middleware. Wenn ein Kunde auf eine Fehler bei Überschreitung des Wiederholungslimits, können Sie feststellen, ob der Fehler beim Client, der Middleware oder dem zugrunde liegenden Cloud Healthcare API-Dienst. Das ist besonders wichtig, wenn Sie finale Fehlerstatus planen.

Stellen Sie sich folgendes Szenario vor:

  1. Die Middleware erhält den Fehler 500 Internal Server Error vom Cloud Healthcare API beim Senden einer Anfrage verwenden.
  2. Die Middleware-Ebene versucht, die Anfrage noch fünfmal zu wiederholen, erreicht das Limit und beendet dann die Wiederholungsversuche.
  3. Der Client erhält einen endgültigen 500 Internal Server Error-Fehler.

Es ist wichtig zu verstehen, dass der Fehler stammten aus der Cloud Healthcare API und nicht aus der Middleware. Bis das Debugging zu vereinfachen, geben Sie diese Informationen in dem Fehler an, der an den Client.

Das folgende Diagramm zeigt ein Szenario, in dem ein Middleware-Proxy 500 Internal Server Error-Fehler beim Weiterleiten einer Anfrage von einem Client an der Cloud Healthcare API. Sowohl der Client als auch der Proxy implementieren die Fehlerbehandlung und Wiederholungen.

Diagramm, in dem dargestellt ist, wo Fehler im Client-/Middleware-/Serverstack behandelt werden
Abbildung 1: Die Schichten, in denen Sie Wiederholungslogik und Zeitüberschreitungen implementieren müssen, sind der Client und der Proxy.

Abbildung 1 zeigt die folgenden Schritte:

  1. Der Client sendet eine gültige Anfrage über einen Middleware-Proxy an die Cloud Healthcare API.
  2. Der Proxy leitet die Anfrage an die Cloud Healthcare API weiter.
  3. Die Cloud Healthcare API gibt dem Proxy den Fehler 500 Internal Server Error zurück. Der Proxy wiederholt die Anfrage fünfmal, bis Das Limit für Wiederholungsversuche wurde erreicht.

  4. Der Proxy gibt den endgültigen Fehlerstatus 500 Internal Server Error an den Client zurück.

    Mit den zuvor gezeigten Empfehlungen können Sie beheben Sie den endgültigen Fehlerstatus, indem Sie den Proxy Folgendes zurückgeben lassen: Fehler an den Client: 

    Error with underlying FHIR store in Cloud Healthcare API after 5 retries: 500 Internal Server Error

    Fügen Sie weitere Informationen zum von der Cloud Healthcare API zurückgegebenen Fehler hinzu.

Manchmal erhält der Client oder Proxy 500 Internal Server Error-Fehler, nachdem das Limit für Wiederholungen erreicht wurde, und kann nicht noch einmal versuchen. In diesem Fall kann ein Mensch um zu ermitteln, ob der Fehler vom Proxy Cloud Healthcare API

Auswählen, welche Fehler wiederholt werden sollen

Je nach Systemarchitektur können Sie und andere ignorieren. Im Folgenden finden Sie eine nicht vollständige Liste der wiederholbaren Cloud Healthcare API Fehlercodes:

  • 408 Request Timeout
  • 425 Too Early
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

Diese Fehler treten normalerweise nicht in der gleichen Häufigkeit oder manchmal gar nicht auf.

Auswirkungen der Systemarchitektur

Die Systemarchitektur beeinflusst, wie und wann Sie Fehler wiederholen.

In einer direkten Client-zu-Server-Architektur kann sich ein Client, der einen 401 UNAUTHENTICATED-Fehler von der Cloud Healthcare API erhält, beispielsweise noch einmal authentifizieren und die Anfrage noch einmal versuchen.

Angenommen, ein System hat eine Middleware-Schicht zwischen dem Client und der Cloud Healthcare API. Wenn sich der Client authentifiziert hat korrekt und mit einem abgelaufenen Authentifizierungstoken Ursache des Problems ist, Die Middleware muss das Token aktualisieren und wiederholen Sie die Anfrage.

Nach der Analyse der endgültigen Fehlerzustände können Sie die Fehler Ihres Kunden anpassen Wiederholungsversuche basierend auf Ihren Ergebnissen.

Endgültige Fehlerstatus planen

Selbst nach der Implementierung von Wiederholungslogik und Zeitüberschreitungen kann ein Client oder eine Middleware Fehler erhalten, bis die Wiederholungen aufgebraucht sind. Der letzte Fehler, der zurückgegeben wird, bevor die Wiederholungen und Zeitüberschreitungen aufgebraucht sind, ist der Endfehlerstatus. Möglicherweise tritt ein abschließender Fehler auf, für Datenkonsistenzfehler.

Manchmal erfordert ein endgültiger Fehlerstatus ein menschliches Eingreifen. Implementieren Sie eine Lösung, um den endgültigen Fehlerstatus für eine Anfrage zu beheben. Andernfalls protokollieren Sie den endgültigen Fehlerstatus, damit er von einem Mitarbeiter überprüft werden kann.

Berücksichtigen Sie bei der Planung des Umgangs mit endgültigen Fehlerzuständen Folgendes:

  • Gibt an, ob Verarbeitungsabhängigkeiten angehalten werden müssen, wenn eine FHIR-Transaktion oder ein FHIR-Bundle nicht erfolgreich abgeschlossen werden kann.
  • Wenn viele VM-Instanzen dauerhaft ausfallen, führt ein Fehler muss der Client die fehlgeschlagenen Anfragen melden. Sobald das Problem behoben ist, muss der Client die Anfragen wiederholen.
  • Monitoring, Benachrichtigungssysteme und Service Level Objectives (SLOs) sind erforderlich, um die Stabilität Ihres Systems zu gewährleisten. Weitere Informationen finden Sie unter Testen und überwachen .

Erhöhte Latenz einplanen

Die Cloud Healthcare API ist ein skalierbarer und leistungsfähiger Dienst. kann die Latenz immer noch aus folgenden Gründen variieren:

  • Auch kleine Unterschiede zwischen Anfragen, die auf den ersten Blick unerheblich erscheinen, können zu einer längeren Verarbeitungszeit führen.
  • Ähnliche Anfragen können unterschiedliche Latenzen haben. Beispielsweise können zwei ähnliche Anfragen, die dem Datenspeicher einen Datensatz hinzufügen, unterschiedliche Latenzen haben, wenn eine Anfrage einen Grenzwert überschreitet, der eine zusätzliche Aufgabe auslöst, z. B. die Zuweisung von mehr Speicherplatz.
  • Die Cloud Healthcare API verarbeitet viele Anfragen gleichzeitig. Die Uhrzeit, zu der ein Client sendet eine Anfrage, gemessen in Sekundenbruchteilen, mit einer Zeit, in der die Cloud Healthcare API stärker als üblich ausgelastet ist.
  • Wenn eine physische Cloud Healthcare API-Ressource, z. B. ein Laufwerk, viele -Anfragen muss er die Aufgaben in der Warteschlange abschließen, bevor er andere Anfragen verarbeiten kann.
  • Manchmal versucht die Cloud Healthcare API, Fehler auf der Serverseite noch einmal auszuführen, was die Latenz für Clients erhöhen kann.
  • Es kann mehrere Kopien von Daten in verschiedenen Rechenzentren in einer oder multiregional. Wenn Ihre Anfragen über in mehreren Rechenzentren, entweder bei der ursprünglichen Anfrage oder bei einem Wiederholungsversuch, kann es zu einer erhöhten Latenz kommen.

Mit Perzentillatenz planen

Sie können die Latenz einplanen, indem Sie die Perzentillatenz Ihre Anfragen. Die Die folgenden Beispiele beschreiben die Latenz des 50. Perzentils und die Latenz des 99. Perzentils:

  • Das 50. Perzentil ist die maximale Latenz in Sekunden für den der schnellsten 50% der Anfragen. Wenn beispielsweise die Latenz des 50. Perzentils 0,5 Sekunden beträgt, hat die Cloud Healthcare API 50 % der Anfragen innerhalb von 0,5 Sekunden verarbeitet. Die Latenz des 50. Perzentils wird auch als die „Medianlatenz“.
  • Die Latenz des 99. Perzentils ist die maximale Latenz in Sekunden für die schnellsten 99 % der Anfragen. Wenn beispielsweise die Latenz des 99. Perzentils zwei Sekunden beträgt, hat die Cloud Healthcare API 99 % der Anfragen innerhalb von zwei Sekunden verarbeitet.

Wenn Sie die Perzentillatenz über ein Intervall analysieren, wenn nur die Cloud Healthcare API weniger Anfragen verarbeitet hat, ist die Perzentillatenz möglicherweise nicht hilfreich oder nicht aussagekräftig. der Gesamtleistung, da Ausreißeranfragen einen großen Einfluss haben können.

Angenommen, ein Prozess in der Cloud Healthcare API verarbeitet 100 Anfragen in 100 Minuten. Die Latenz des 99. Perzentils für die 100 Minuten basiert auf der einzelnen langsamsten Anfrage. Eine Latenzmessung mit einer einzelnen Anfrage reicht nicht aus, um festzustellen, ob Leistungsprobleme vorliegen.

Wenn Sie eine größere Anfragestichprobe über einen längeren Zeitraum erfassen, z. B. 24 Stunden, erhalten Sie mehr Informationen zum Gesamtverhalten Ihres Systems. Anhand dieser Beispiele können Sie feststellen, bei starkem Verkehr.