Ottimizzazione della latenza di rete

Questo documento elenca le best practice per l'utilizzo dell'API Cloud Healthcare. Le linee guida in questa pagina sono progettate per una maggiore efficienza, accuratezza e tempi di risposta ottimali da parte del servizio.

Informazioni sulle prestazioni di latenza

Le prestazioni dell'API Cloud Healthcare vengono misurate in base alla latenza tra:

  1. Quando invii una richiesta all'API Cloud Healthcare,
  2. Quando ricevi una risposta completa alla richiesta.

La latenza è composta da tre componenti:

  • Tempo di round trip (RTT)
  • Latenza di elaborazione del server
  • Velocità effettiva del server

La distanza geografica tra te e il server a cui stai inviando richieste può avere un impatto significativo sulla RTT e sulla velocità effettiva del server. La latenza e la velocità effettiva tra aree geografiche misurate per le reti Google Cloud sono disponibili in una dashboard dal vivo. La dashboard mostra le prestazioni che un client può aspettarsi da località diverse quando invia richieste ai server API Cloud Healthcare.

Misurazione delle prestazioni di latenza

I seguenti strumenti e dashboard forniscono modi per misurare le prestazioni delle richieste da e verso i server API Cloud Healthcare:

  • Metriche di latenza della console Google Cloud: puoi visualizzare la latenza lato server delle richieste API Cloud Healthcare nella console Google Cloud. Per saperne di più, consulta Metriche di Google Cloud.

  • Metriche personalizzate di Cloud Logging: puoi creare metriche di distribuzione utilizzando Logging. Le metriche di distribuzione consentono di configurare e comprendere la latenza end-to-end nelle applicazioni. Puoi anche monitorare e creare report su qualsiasi misurazione della latenza personalizzata.

  • Riquadro della rete di Chrome: puoi controllare l'attività di rete in Chrome DevTools per visualizzare i dettagli sulle prestazioni di una richiesta HTTP inviata da un browser.

Riduzione della latenza delle richieste

Questa sezione descrive vari metodi per ridurre la latenza delle richieste inviate all'API Cloud Healthcare.

Invio di richieste alla località regionale più vicina in corso...

Per ottenere le migliori prestazioni di velocità effettiva del server e RTT, invia le richieste dal client alla località a livello di regione dell'API Cloud Healthcare più vicina. Consulta la sezione Regioni per un elenco delle regioni disponibili.

Compressione del corpo della risposta

Se un client ha una larghezza di banda limitata, un modo semplice per ridurre la larghezza di banda necessaria per ogni richiesta è attivare la compressione gzip. gzip è una forma di compressione dei dati: in genere riduce le dimensioni di un file. In questo modo il file verrà trasferito più velocemente e archiviato usando meno spazio rispetto a se non fosse compresso. La compressione di un file può ridurre sia i costi che il tempo di trasferimento.

Sebbene l'attivazione della compressione gzip richieda più tempo di CPU per estrarre i risultati, il vantaggio del risparmio di larghezza di banda in genere vale la pena utilizzare la compressione gzip. Tuttavia, se la larghezza di banda limitata non è un problema, i vantaggi della compressione gzip non saranno validi.

Per ricevere una risposta con codifica gzip, devi impostare un'intestazione Accept-Encoding nella richiesta.

L'esempio seguente mostra un'intestazione HTTP formattata correttamente per consentire la compressione gzip:

Accept-Encoding: gzip

Invio richieste di warmup

Quando un client invia richieste a un server API Cloud Healthcare per la prima volta durante una sessione, il client esegue handshake TCP con il server per stabilire le connessioni per le richieste HTTP. Qualsiasi richiesta successiva può continuare a utilizzare queste connessioni stabilite, consentendo al client di evitare le spese generali TCP, generalmente associate a una richiesta. Il risultato è un rendimento migliore durante l'invio di richieste.

Invio di richieste contemporaneamente con HTTP/1.1 o HTTP/2

Per ottenere il miglior rendimento possibile per una serie di richieste, invia contemporaneamente le richieste. Attieniti alle linee guida che seguono quando invii richieste in parallelo:

  • Quando invii richieste in parallelo, cerca il numero ideale per il numero di richieste in parallelo. Il numero ideale dipende da diversi fattori, tra cui le funzionalità hardware e di rete e il numero di richieste inviate. Fai dei test per trovare il numero ideale.
  • Se possibile, invia richieste dal client tramite HTTP/2. HTTP/2 offre prestazioni migliori rispetto a HTTP/1,1 perché HTTP/2 richiede una sola connessione TCP quando si inviano più richieste in sequenza o contemporaneamente. Di conseguenza, puoi evitare l'overhead di handshake TCP.

  • Se non è possibile utilizzare HTTP/2, utilizza HTTP/1.1 con una connessione permanente. Puoi evitare l'overhead di handshake TCP se sono già state inviate richieste di avviso. L'utilizzo di una connessione permanente potrebbe richiedere la gestione di una connessione ottimizzata con un pool di connessioni per la libreria HTTP.

    Ad esempio, per impostare un pool di connessioni con 20 richieste in parallelo utilizzando la libreria client HTTP di Google per Java, il codice include quanto segue:

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

    Per impostare un pool di connessioni con 20 richieste in parallelo che utilizzano Node.js, il codice include quanto segue:

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