Problemi di prestazioni e latenza dell'applicazione

L'impatto della latenza del livello di comunicazione è tipicamente sottovalutato quando si cerca di risolvere i problemi di performance delle applicazioni, ma la corretta comprensione è fondamentale se si vogliono indirizzare i propri sforzi verso soluzioni pratiche.

In primo luogo, per latenza del livello di comunicazione intendo il tempo necessario ad un pacchetto per passare dal sistema locale al sistema remoto e viceversa. Il fattore più importante nella latenza del livello di comunicazione è la distanza - almeno per gli host geograficamente separati. L'altro componente principale è il numero di dispositivi tra gli host locali e remoti che elaborano i pacchetti; questo include cose come router e firewall. La larghezza di banda dei collegamenti gioca un ruolo, ma non così grande come la maggior parte delle persone pensa. La larghezza di banda influisce sul ritardo di inserimento - quanto tempo ci vuole per mettere un pacchetto sul filo ma il segnale sul filo viaggia ad una velocità basata sul mezzo e non sulla larghezza di banda. Per il resto di questa discussione mi limiterò a usare la latenza quando parlo di latenza del livello di comunicazione.

Per dimostrare come la latenza influisce sulla vostra applicazione, diciamo che inserite alcuni dati in un'applicazione client e cliccate su "Return". L'applicazione client invia un messaggio a un'applicazione server, attende una risposta e poi ne invia un altro, attende una risposta, ecc. Alla fine di N giri l'applicazione client vi presenta i risultati.

Supponiamo che siano necessari 10 turni e che l'applicazione server richieda 1 ms per elaborare il messaggio del client e inviare una risposta. Con una latenza di 1ms si ottiene un tempo di risposta di 10 * (1ms + 1ms) o 20ms. Ora salite su un aereo e andate a Chicago, il server rimane a Boston, quindi ora avete una latenza di diciamo 50ms e un tempo di risposta di 10 * (50ms + 1ms) o 550ms. Questo è sufficiente per essere evidente ma non doloroso. Aumentate il numero di giri a 100 e avrete ora un doloroso tempo di risposta di 5,5 secondi e mezzo. Si può pensare che 100 turni siano eccessivi, ma alcune complesse query di database o applicazioni che riempiono moduli complessi possono fare proprio questo. Sapete quanti turni richiedono le vostre domande?
Anche fare un copy_file via OSL mostra questo comportamento. OSL invierà un file in 4K transazioni. Ogni transazione richiede una risposta, quindi un file da 1.000.000 byte richiederà 1.000.000 / 4.096 = 245 transazioni o giri per utilizzare la nomenclatura del paragrafo precedente. Anche in questo caso, assumendo 1ms per elaborare la transazione e una latenza di 1ms il copy_file richiederà 490ms. Se aumentiamo la latenza a 50ms ci vorranno 12.495 secondi. Se aumentiamo il file a 1.000.000.000.000 di byte, saranno necessarie 244.141 transazioni; con tempi corrispondenti di 488,282 secondi per una latenza di 1ms e 12.451,191 secondi o quasi 3,5 ore per una latenza di 50ms.

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

È anche possibile utilizzare un programma che ho scritto che cronometra le connessioni senza bisogno di utilizzare packet_monitor. Vedere http://members.cox.net/ndav1/self_published/stcp_tping.doc. Il comando stcp_tping richiede la connessione 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 una richiesta verrà inviata una volta al secondo.