Netzwerklatenz optimieren

Dieses Dokument enthält Best Practices für die Verwendung der Cloud Healthcare API. Die Richtlinien auf dieser Seite sind auf eine höhere Effizienz, Genauigkeit und optimale Antwortzeiten des Dienstes ausgelegt.

Informationen zur Latenzleistung

Die Leistung der Cloud Healthcare API wird anhand der Latenz zwischen:

  1. Wenn Sie eine Anfrage an die Cloud Healthcare API senden
  2. Wenn Sie eine vollständige Antwort auf die Anfrage erhalten

Latenz setzt sich aus drei Komponenten zusammen:

  • Umlaufzeit (round-trip time – RTT)
  • Latenz der Serververarbeitung
  • Serverdurchsatz

Die geografische Entfernung zwischen Ihnen und dem Server, an den Sie Anfragen senden, kann sich erheblich auf RTT- und Serverdurchsatz auswirken. Die regionenübergreifende Latenz und der Durchsatz für Google Cloud-Netzwerke finden Sie in einem Live-Dashboard. Das Dashboard zeigt die Leistung, die ein Client von verschiedenen Standorten aus erwarten kann, wenn Anfragen an Cloud Healthcare API-Server gesendet werden.

Latenzleistung messen

Die folgenden Tools und Dashboards bieten Möglichkeiten zur Messung der Leistung von Anfragen an und zu Cloud Healthcare API-Servern:

  • Latenzmesswerte der Google Cloud Console: Sie können die serverseitige Latenz von Cloud Healthcare API-Anfragen in der Google Cloud Console ansehen. Weitere Informationen finden Sie unter Google Cloud-Messwerte.

  • Benutzerdefinierte Cloud Logging-Messwerte: Sie können mit Logging Verteilungsmesswerte erstellen. Mithilfe von Verteilungsmesswerten können Sie die End-to-End-Latenz in Ihren Anwendungen konfigurieren und verstehen. Sie können auch benutzerdefinierte Latenzmessungen überwachen und entsprechende Berichte erstellen.

  • Feld "Chrome-Netzwerk": Sie können die Netzwerkaktivität in den Chrome DevTools ansehen, um die Leistungsdetails einer HTTP-Anfrage anzuzeigen, die von einem Browser gesendet wurde.

Anfragenlatenz verringern

In diesem Abschnitt werden verschiedene Methoden beschrieben, um die Latenz von Anfragen zu reduzieren, die an die Cloud Healthcare API gesendet werden.

Anfragen werden an den nächstgelegenen regionalen Standort gesendet

Senden Sie Anfragen vom Client an den nächstgelegenen regionalen Standort der Cloud Healthcare API, um die beste RTT- und Serverdurchsatzleistung zu erzielen. Eine Liste der verfügbaren Regionen finden Sie unter Regionen.

Antworttext komprimieren

Wenn ein Client eine begrenzte Bandbreite hat, können Sie die für jede Anfrage benötigte Bandbreite einfach reduzieren, indem Sie die GZIP-Komprimierung aktivieren. gzip ist eine Form der Datenkomprimierung, die in der Regel die Größe einer Datei reduziert. So kann sie schneller übertragen werden und benötigt weniger Speicherplatz, als wenn sie nicht komprimiert wäre. Durch das Komprimieren von Dateien sparen Sie sowohl Kosten als auch Übertragungszeit.

Das Aktivieren der gzip-Komprimierung erfordert zusätzliche CPU-Zeit für die Extraktion der Ergebnisse. Der Vorteil der Speichern der Bandbreite macht jedoch in der Regel eine gzip-Komprimierung. Wenn die beschränkte Bandbreite jedoch kein Problem darstellt, sind die Vorteile der GZIP-Komprimierung nicht wert.

Wenn Sie eine mit gzip codierte Antwort erhalten möchten, müssen Sie in Ihrer Anfrage einen Accept-Encoding-Header festlegen.

Das folgende Beispiel zeigt einen korrekt formatierten HTTP-Header zum Aktivieren der GZIP-Komprimierung:

Accept-Encoding: gzip

Aufwärmanfragen senden

Wenn zum ersten Mal während einer Sitzung Anfragen an einen Cloud Healthcare API-Server gesendet werden, führt der Client TCP-Handshakes mit dem Server aus, um Verbindungen für HTTP-Anfragen herzustellen. Alle nachfolgenden Anfragen können diese etablierten Verbindungen weiter verwenden, sodass der Client den TCP-Overhead vermeiden kann, der normalerweise mit einer Anfrage verknüpft ist. Dies führt zu einer besseren Leistung beim Senden von Anfragen.

Gleichzeitige Requests mit HTTP/1.1 oder HTTP/2 senden

Um die beste Leistung für eine Reihe von Anfragen zu erzielen, senden Sie die Anfragen gleichzeitig. Beachten Sie beim Senden gleichzeitiger Anfragen die folgenden Richtlinien:

  • Versuchen Sie beim Senden gleichzeitiger Anfragen, eine ideale Zahl für die Anzahl der gleichzeitigen Anfragen zu finden. Die ideale Anzahl hängt von mehreren Faktoren ab, unter anderem von der Hardware- und Netzwerkkapazität und der Anzahl der Anfragen. Führen Sie Tests durch, um die ideale Zahl zu ermitteln.
  • Senden Sie nach Möglichkeit Anfragen vom Client mit HTTP/2. HTTP/2 bietet eine bessere Leistung als HTTP/1.1, da HTTP/2 nur eine TCP-Verbindung benötigt, wenn mehrere Anfragen nacheinander oder gleichzeitig gesendet werden. Daher können Sie den Aufwand für TCP-Handshake vermeiden.

  • Wenn HTTP/2 nicht verwendet werden kann, verwenden Sie HTTP/1.1 mit einer persistenten Verbindung. Sie können den TCP-Handshake-Overhead vermeiden, wenn bereits Aufwärmanfragen gesendet wurden. Wenn Sie eine persistente Verbindung verwenden, müssen Sie möglicherweise eine optimierte Verbindung mit einem Verbindungspool für Ihre HTTP-Bibliothek verwalten.

    Zum Einrichten eines Verbindungspool mit 20 gleichzeitigen Anfragen mithilfe der Google HTTP-Clientbibliothek für Java enthält Ihr Code beispielsweise Folgendes:

    PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
// Support 20 concurrent requests.
cm.setDefaultMaxPerRoute(20);
cm.setMaxTotal(100);
HTTP_CLIENT = HttpClients.custom().setConnectionManager(cm).build();

    Zum Festlegen eines Verbindungspool mit 20 gleichzeitigen Anfragen mit Node.js würde Ihr Code Folgendes enthalten:

    require('http').globalAgent.maxSockets = 20