Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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:
Wenn Sie eine Anfrage an die Cloud Healthcare API senden
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:
Google Cloud Console-Latenzmesswerte: 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.
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.
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:
PoolingHttpClientConnectionManagercm=newPoolingHttpClientConnectionManager();// 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:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-03 (UTC)."],[[["\u003cp\u003eThis document outlines best practices for enhancing efficiency, accuracy, and response times when using the Cloud Healthcare API.\u003c/p\u003e\n"],["\u003cp\u003eLatency in the Cloud Healthcare API is determined by the time between sending a request and receiving a full response, and is impacted by factors like round-trip time (RTT) and server throughput.\u003c/p\u003e\n"],["\u003cp\u003eTools like Google Cloud console latency metrics, Cloud Logging custom metrics, and the Chrome network panel can be used to measure the performance of requests to and from Cloud Healthcare API servers.\u003c/p\u003e\n"],["\u003cp\u003eTo reduce request latency, send requests to the nearest Cloud Healthcare API regional location, send warmup requests to establish connections, and send concurrent requests using HTTP/2 or HTTP/1.1 with persistent connections.\u003c/p\u003e\n"],["\u003cp\u003eUsing a persistent connection might require you to manage an optimized connection with a connection pool for your HTTP library, and the number of concurrent requests should be tested for your specific usage.\u003c/p\u003e\n"]]],[],null,["# Network latency best practices\n\nThis document lists best practices for using the Cloud Healthcare API.\nThe guidelines in this page are designed for greater efficiency, accuracy, and\noptimal response times from the service.\n\nUnderstanding latency performance\n---------------------------------\n\nThe performance of the Cloud Healthcare API is measured by the latency\nbetween:\n\n1. When you send a request to the Cloud Healthcare API.\n2. When you receive a full response to the request.\n\nLatency comprises three components:\n\n- Round-trip time (RTT)\n- Server processing latency\n- Server throughput\n\nThe geographical distance between you and the server you are making requests\nto can have a significant impact on RTT and server throughput. The measured\ninter-region latency and throughput for Google Cloud networks can be found in a\n[live dashboard](https://lookerstudio.google.com/c/u/0/reporting/fc733b10-9744-4a72-a502-92290f608571/page/70YCB).\nThe dashboard shows the performance a client can expect from different\nlocations when making requests to Cloud Healthcare API servers.\n\nMeasuring latency performance\n-----------------------------\n\nThe following tools and dashboards provide ways to measure the performance\nof requests to and from Cloud Healthcare API servers:\n\n- **Google Cloud console latency metrics** : You can view the server-side latency\n of Cloud Healthcare API requests in the [Google Cloud console](https://console.cloud.google.com/apis/api/healthcare.googleapis.com/metrics).\n For more information, see [Google Cloud metrics](/monitoring/api/metrics_gcp).\n\n- **Cloud Logging custom metrics** : You can [create distribution metrics](/logging/docs/logs-based-metrics/distribution-metrics)\n using Logging. Distribution metrics let you configure and\n understand end-to-end latency in your applications. You can also monitor and\n report on any custom-defined latency measurements.\n\n- **Chrome network panel** : You can [inspect network activity in Chrome DevTools](https://developers.google.com/web/tools/chrome-devtools/network)\n to view the performance details of an HTTP request sent from a browser.\n\nReducing request latency\n------------------------\n\nThis section describes various methods of reducing the latency of requests sent\nto the Cloud Healthcare API.\n\n### Sending requests to the closest regional location\n\nTo get the best RTT and server throughput performance, send requests from the\nclient to the closest Cloud Healthcare API regional location. See\n[Regions](/healthcare-api/docs/concepts/regions) for a list of available regions.\n\n### Sending warmup requests\n\nWhen a client sends requests to a Cloud Healthcare API server for the\nfirst time during a session, the client performs TCP handshakes with the\nserver to establish connections for HTTP requests. Any subsequent requests\ncan continue to use these established connections, allowing the client to\navoid the TCP overhead typically associated with a request. This results\nin better performance when sending requests.\n\n### Sending requests concurrently with HTTP/1.1 or HTTP/2\n\nTo obtain the best performance for a series of requests, send the requests\nconcurrently. Use the following guidelines when sending concurrent requests:\n\n- When sending concurrent requests, try to find an ideal number for the number of concurrent requests. The ideal number depends on several factors including your hardware and network capabilities and how many requests are being sent. Conduct tests to find the ideal number.\n- Send requests from the client using HTTP/2 whenever possible. HTTP/2 provides better performance than HTTP/1.1 because HTTP/2 requires only one TCP connection when sending multiple requests sequentially or concurrently. As a result, you can avoid TCP handshake overhead.\n- If it's not possible to use HTTP/2, use HTTP/1.1 with a persistent connection.\n You can avoid TCP handshake overhead if [warmup requests](#sending_warmup_requests)\n have already been sent. Using a persistent connection might require you to\n manage an optimized connection with a connection pool for your HTTP library.\n\n For example, to set a connection pool with 20 concurrent requests using the [Google HTTP client library for Java](https://github.com/googleapis/google-http-java-client), your code would include the following: \n\n PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();\n // Support 20 concurrent requests.\n cm.setDefaultMaxPerRoute(20);\n cm.setMaxTotal(100);\n HTTP_CLIENT = HttpClients.custom().setConnectionManager(cm).build();\n\n To set a connection pool with 20 concurrent requests using Node.js, your code\n would include the following: \n\n require('http').globalAgent.maxSockets = 20"]]
