Problemi di prestazioni delle applicazioni e latenza

L'impatto della latenza del livello di comunicazione viene solitamente sottovalutato quando si cerca di risolvere i problemi di prestazioni delle applicazioni, ma una corretta comprensione è fondamentale se si desidera orientare i propri sforzi verso soluzioni pratiche.

Innanzitutto, per latenza del livello di comunicazione intendo il tempo impiegato da un pacchetto per arrivare dal sistema locale al sistema remoto e tornare indietro. Il fattore più importante nella latenza del livello di comunicazione è la distanza, almeno per gli host geograficamente separati. L'altra componente importante è il numero di dispositivi tra gli host locali e remoti che elaborano i pacchetti, inclusi router e firewall. La larghezza di banda dei collegamenti ha un ruolo importante, ma non così rilevante come molti pensano. La larghezza di banda influisce sul ritardo di inserimento, ovvero il tempo necessario per inviare un pacchetto sulla linea, ma il segnale sulla linea viaggia a una velocità basata sul mezzo di trasmissione e non sulla larghezza di banda. Nel resto di questa discussione userò semplicemente il termine "latenza" quando mi riferisco alla latenza del livello di comunicazione.

Per dimostrare come la latenza influisca sulla tua applicazione, supponiamo che tu inserisca alcuni dati in un'applicazione client e premi Invio. L'applicazione client invia un messaggio a un'applicazione server, attende una risposta e quindi invia un altro messaggio, attende una risposta e così via per un certo numero N di "turni". Al termine dei N turni, l'applicazione client ti presenta i risultati.

Supponiamo che siano necessari 10 turni e che l'applicazione server impieghi 1 ms per elaborare il messaggio del client e inviare una risposta. Con una latenza di 1 ms, il tempo di risposta è pari a 10 * (1 ms + 1 ms) ovvero 20 ms. Ora prendiamo un aereo e voliamo a Chicago: il server rimane a Boston, quindi la latenza è pari a circa 50 ms e il tempo di risposta è pari a 10 * (50 ms + 1 ms) ovvero 550 ms. Si tratta di un tempo sufficiente per essere percepito, ma non fastidioso. Aumenta il numero di turni a 100 e ora avrai un tempo di risposta fastidioso di 5,5 secondi. Potresti pensare che 100 turni siano eccessivi, ma alcune query di database complesse o applicazioni che compilano moduli complessi possono fare proprio questo. Sapete quanti turni richiedono le vostre applicazioni?
Anche l'esecuzione di un copy_file tramite OSL mostra questo comportamento. OSL invierà un file in transazioni da 4K. Ogni transazione richiede una risposta, quindi un file da 1.000.000 byte richiederà 1.000.000 / 4.096 = 245 transazioni o turni, per usare la nomenclatura del paragrafo precedente. Ancora una volta, ipotizzando 1 ms per elaborare la transazione e una latenza di 1 ms, il comando copy_file richiederà 490 ms. Se aumentiamo la latenza a 50 ms, saranno necessari 12,495 secondi. Se aumentiamo il file a 1.000.000.000 byte, saranno necessarie 244.141 transazioni, con tempi corrispondenti di 488,282 secondi per una latenza di 1 ms e 12.451,191 secondi, ovvero quasi 3,5 ore, per una latenza di 50 ms.

Il modo più semplice per misurare la latenza è con il ping.

È anche possibile utilizzare un programma che ho scritto che misura i tempi delle connessioni senza bisogno di usare packet_monitor. Vedere http://members.cox.net/ndav1/self_published/stcp_tping.doc. Il comando stcp_tping richiede che ci si connetta a una porta attiva sull'host remoto. In questo caso sto usando la porta 23 (telnet), ma qualsiasi porta attiva funzionerà. Il numero 1 alla fine del comando indica che verrà inviata una richiesta al secondo.