Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En este documento, se enumeran las prácticas recomendadas para usar la API de Cloud Healthcare.
Los lineamientos que se indican en esta página se diseñaron para aumentar la eficiencia, la exactitud y los tiempos de respuesta óptimos del servicio.
Comprende el rendimiento de la latencia
El rendimiento de la API de Cloud Healthcare se mide mediante la latencia entre los siguientes elementos:
Cuando envías una solicitud a la API de Cloud Healthcare.
Cuando recibes una respuesta completa a la solicitud.
La latencia consta de tres componentes:
Tiempo de ida y vuelta (RTT)
Latencia de procesamiento del servidor
Capacidad de procesamiento del servidor
La distancia geográfica entre tú y el servidor al que realizas las solicitudes puede tener un impacto significativo en el RTT y la capacidad de procesamiento del servidor. La latencia y la capacidad de procesamiento interregionales medidas para las redes de Google Cloud se pueden encontrar en un panel en vivo.
En el panel, se muestra el rendimiento que un cliente puede esperar de diferentes ubicaciones cuando realiza solicitudes a los servidores de la API de Cloud Healthcare.
Mide el rendimiento de la latencia
Los siguientes paneles y herramientas proporcionan formas de medir el rendimiento de las solicitudes desde y hacia los servidores de la API de Cloud Healthcare:
Métricas de latencia deGoogle Cloud console: Puedes ver la latencia del servidor de las solicitudes a la API de Cloud Healthcare en Google Cloud console.
Para obtener más información, consulta Métricas deGoogle Cloud .
Métricas personalizadas de Cloud Logging: Puedes crear métricas de distribución mediante Logging. Las métricas de distribución te permiten configurar y comprender la latencia de extremo a extremo en tus aplicaciones. También puedes supervisar e informar sobre cualquier medida de latencia definida de forma personalizada.
En esta sección, se describen varios métodos para reducir la latencia de las solicitudes enviadas a la API de Cloud Healthcare.
Envía solicitudes a la ubicación regional más cercana
Para obtener el mejor rendimiento de la capacidad de procesamiento del servidor y RTT, envía solicitudes del cliente a la ubicación regional de la API de Cloud Healthcare más cercana. Consulta Regiones para ver una lista de las regiones disponibles.
Envía solicitudes de preparación
Cuando un cliente envía solicitudes a un servidor de la API de Cloud Healthcare por primera vez durante una sesión, el cliente realiza protocolos de enlace TCP con el servidor a fin de establecer conexiones para las solicitudes HTTP. Las solicitudes posteriores pueden seguir usando estas conexiones establecidas, lo que permite que el cliente evite la sobrecarga de TCP que se suele asociar con una solicitud. Esto da como resultado un mejor rendimiento cuando se envían solicitudes.
Envía solicitudes simultáneamente con HTTP/1.1 o HTTP/2
Para obtener el mejor rendimiento de una serie de solicitudes, envíalas simultáneamente. Usa los siguientes lineamientos para enviar solicitudes simultáneas:
Cuando envíes solicitudes simultáneas, intenta encontrar un número ideal para la cantidad de solicitudes simultáneas. La cantidad ideal de datos depende de varios factores, como las capacidades de hardware y red, y la cantidad de solicitudes que se envían.
Realiza pruebas para encontrar el número ideal.
Envía solicitudes del cliente mediante HTTP/2 siempre que sea posible. HTTP/2 proporciona un mejor rendimiento que HTTP/1.1, ya que HTTP/2 requiere solo una conexión TCP cuando se envían varias solicitudes de forma secuencial o simultánea. Como resultado, puedes evitar la sobrecarga del protocolo de enlace de TCP.
Si no es posible usar HTTP/2, usa HTTP/1.1 con una conexión persistente.
Puedes evitar la sobrecarga del protocolo de enlace TCP si ya se enviaron las solicitudes de preparación. El uso de una conexión persistente puede requerir que administres una conexión optimizada con un grupo de conexiones para tu biblioteca HTTP.
PoolingHttpClientConnectionManagercm=newPoolingHttpClientConnectionManager();// Support 20 concurrent requests.cm.setDefaultMaxPerRoute(20);cm.setMaxTotal(100);HTTP_CLIENT=HttpClients.custom().setConnectionManager(cm).build();
Para configurar un grupo de conexión con 20 solicitudes simultáneas mediante Node.js, tu código incluiría lo siguiente:
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-05 (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"]]
