Prácticas recomendadas para reducir la latencia de la red
Organízate con las colecciones
Guarda y clasifica el contenido según tus preferencias.
En este documento se enumeran las prácticas recomendadas para usar la API Cloud Healthcare.
Las directrices de esta página se han diseñado para que el servicio sea más eficiente y preciso, y para que los tiempos de respuesta sean óptimos.
Interpretar el rendimiento de la latencia
El rendimiento de la API Cloud Healthcare se mide por la latencia entre los siguientes elementos:
Cuando envías una solicitud a la API Cloud Healthcare.
Cuando recibas una respuesta completa a la solicitud.
La latencia consta de tres componentes:
Tiempo de ida y vuelta (RTT)
Latencia de procesamiento del servidor
Rendimiento del servidor
La distancia geográfica entre tú y el servidor al que envías solicitudes puede influir significativamente en el RTT y en el rendimiento del servidor. La latencia y el rendimiento medidos entre regiones de las redes de Google Cloud se pueden consultar en un panel de control en directo.
El panel de control muestra el rendimiento que puede esperar un cliente de diferentes ubicaciones al enviar solicitudes a los servidores de la API Cloud Healthcare.
Medir el rendimiento de la latencia
Las siguientes herramientas y paneles de control ofrecen formas de medir el rendimiento de las solicitudes a los servidores de la API Cloud Healthcare y desde ellos:
Google Cloud Métricas de latencia de la consola: puedes ver la latencia del lado del servidor de las solicitudes a la API Cloud Healthcare en la Google Cloud consola.
Para obtener más información, consulta las métricas deGoogle Cloud .
Métricas personalizadas de Cloud Logging: puedes crear métricas de distribución con Logging. Las métricas de distribución te permiten configurar y comprender la latencia de extremo a extremo de tus aplicaciones. También puede monitorizar y generar informes sobre cualquier medición 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 Cloud Healthcare.
Enviar solicitudes a la ubicación regional más cercana
Para obtener el mejor rendimiento de RTT y de resultados del servidor, envíe solicitudes del cliente a la ubicación regional de la API de Cloud Healthcare más cercana. Consulta la lista de regiones disponibles en Regiones.
Enviar solicitudes de preparación
Cuando un cliente envía solicitudes a un servidor de la API Cloud Healthcare por primera vez durante una sesión, el cliente realiza negociaciones TCP con el servidor para 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 suele asociarse a una solicitud. Esto se traduce en un mejor rendimiento al enviar solicitudes.
Enviar solicitudes simultáneamente con HTTP/1.1 o HTTP/2
Para obtener el mejor rendimiento en una serie de solicitudes, envíalas simultáneamente. Sigue estas directrices cuando envíes solicitudes simultáneas:
Cuando envíe solicitudes simultáneas, intente encontrar el número ideal de solicitudes simultáneas. El número ideal depende de varios factores, como las funciones de tu hardware y tu red, y el número de solicitudes que se envían.
Haz pruebas para encontrar el número ideal.
Envía solicitudes desde el cliente mediante HTTP/2 siempre que sea posible. HTTP/2 ofrece un mejor rendimiento que HTTP/1.1 porque solo requiere una conexión TCP al enviar varias solicitudes de forma secuencial o simultánea. Como resultado, puedes evitar la sobrecarga de la negociación TCP.
Si no es posible usar HTTP/2, usa HTTP/1.1 con una conexión persistente.
Puedes evitar la sobrecarga de la negociación TCP si ya se han enviado solicitudes de calentamiento. Para usar una conexión persistente, es posible que tengas que gestionar 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 definir un grupo de conexiones con 20 solicitudes simultáneas con Node.js, tu código
incluiría lo siguiente:
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-10 (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"]]
