Optimizar en función de la latencia de la red

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:

  1. Cuando envías una solicitud a la API de Cloud Healthcare.
  2. 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:

Reduce la latencia de las solicitudes

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.

Comprime el cuerpo de la respuesta

Si un cliente tiene un ancho de banda limitado, una forma sencilla de reducir el ancho de banda necesario para cada solicitud es habilitar la compresión de gzip. gzip es una forma de compresión de datos: reduce el tamaño de un archivo de forma típica. Esto permite que el archivo se pueda transferir más rápido y se pueda almacenar con menos uso de espacio que si no estuviera comprimido. Comprimir un archivo puede reducir costos y el tiempo de transferencia.

Aunque habilitar la compresión de gzip requiere tiempo de CPU adicional para extraer los resultados, el beneficio de ahorrar ancho de banda suele hacer que la compresión de gzip valga la pena. Sin embargo, si el ancho de banda limitado no es una preocupación, los beneficios de la compresión de gzip no valen la pena.

Para recibir una respuesta codificada en gzip, debes configurar un encabezado Accept-Encoding en tu solicitud.

En la siguiente muestra, se muestra un encabezado HTTP con el formato correcto para habilitar la compresión de gzip:

Accept-Encoding: gzip

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.

    Por ejemplo, para configurar un grupo de conexión con 20 solicitudes simultáneas mediante la biblioteca cliente HTTP de Google para Java, el código incluiría lo siguiente:

    PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
// 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:

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