Práticas recomendadas para a latência de rede

Este documento apresenta práticas recomendadas para usar a Cloud Healthcare API. As diretrizes nesta página foram concebidas para uma maior eficiência, precisão e tempos de resposta ideais do serviço.

Compreender o desempenho da latência

O desempenho da API Cloud Healthcare é medido pela latência entre:

  1. Quando envia um pedido para a Cloud Healthcare API.
  2. Quando recebe uma resposta completa ao pedido.

A latência compreende três componentes:

  • Tempo de ida e volta (RTT)
  • Latência de processamento do servidor
  • Débito do servidor

A distância geográfica entre si e o servidor ao qual está a enviar pedidos pode ter um impacto significativo no RTT e no débito do servidor. Pode encontrar a latência entre regiões e o débito medidos para as redes Google Cloud num painel de controlo em direto. O painel de controlo mostra o desempenho que um cliente pode esperar de diferentes localizações quando faz pedidos aos servidores da Cloud Healthcare API.

Medir o desempenho da latência

As seguintes ferramentas e painéis de controlo oferecem formas de medir o desempenho dos pedidos enviados para e recebidos dos servidores da Cloud Healthcare API:

  • Google Cloud Métricas de latência da consola: pode ver a latência do lado do servidor dos pedidos da API Cloud Healthcare na Google Cloud consola. Para mais informações, consulte as Google Cloud métricas.

  • Métricas personalizadas do Cloud Logging: pode criar métricas de distribuição com o Logging. As métricas de distribuição permitem-lhe configurar e compreender a latência ponto a ponto nas suas aplicações. Também pode monitorizar e criar relatórios sobre quaisquer medições de latência definidas pelo utilizador.

  • Painel de rede do Chrome: pode inspecionar a atividade da rede nas Chrome DevTools para ver os detalhes de desempenho de um pedido HTTP enviado a partir de um navegador.

Reduzir a latência dos pedidos

Esta secção descreve vários métodos de redução da latência dos pedidos enviados para a Cloud Healthcare API.

Enviar pedidos para a localização regional mais próxima

Para obter o melhor desempenho de RTT e débito do servidor, envie pedidos do cliente para a localização regional da API Cloud Healthcare mais próxima. Consulte a secção Regiões para ver uma lista das regiões disponíveis.

A enviar pedidos de aquecimento

Quando um cliente envia pedidos a um servidor da Cloud Healthcare API pela primeira vez durante uma sessão, o cliente realiza negociações TCP com o servidor para estabelecer ligações para pedidos HTTP. Todos os pedidos subsequentes podem continuar a usar estas ligações estabelecidas, o que permite ao cliente evitar a sobrecarga de TCP normalmente associada a um pedido. Isto resulta num melhor desempenho ao enviar pedidos.

Enviar pedidos em simultâneo com HTTP/1.1 ou HTTP/2

Para obter o melhor desempenho para uma série de pedidos, envie os pedidos em simultâneo. Siga as seguintes diretrizes quando enviar pedidos simultâneos:

  • Ao enviar pedidos simultâneos, tente encontrar um número ideal para o número de pedidos simultâneos. O número ideal depende de vários fatores, incluindo as capacidades de hardware e de rede, e o número de pedidos que estão a ser enviados. Faça testes para encontrar o número ideal.
  • Envie pedidos do cliente através de HTTP/2 sempre que possível. O HTTP/2 oferece um melhor desempenho do que o HTTP/1.1 porque o HTTP/2 requer apenas uma ligação TCP quando envia vários pedidos sequencial ou simultaneamente. Como resultado, pode evitar a sobrecarga do handshake TCP.

  • Se não for possível usar o HTTP/2, use o HTTP/1.1 com uma ligação persistente. Pode evitar a sobrecarga do handshake TCP se já tiverem sido enviados pedidos de preparação. A utilização de uma ligação persistente pode exigir que faça a gestão de uma ligação otimizada com um conjunto de ligações para a sua biblioteca HTTP.

    Por exemplo, para definir um conjunto de ligações com 20 pedidos simultâneos através da biblioteca cliente HTTP da Google para Java, o seu código incluiria o seguinte:

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

    Para definir um conjunto de ligações com 20 pedidos simultâneos através do Node.js, o seu código incluiria o seguinte:

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