Passa al contenuto principale

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.

ping 192.168.200.197
Pinging host 192.168.200.197 : 192.168.200.197
ICMP Echo Reply:TTL 53 time = 84 ms
ICMP Echo Reply:TTL 53 time = 80 ms
ICMP Echo Reply:TTL 53 time = 81 ms
ICMP Echo Reply:TTL 53 time = 96 ms
Host 192.168.200.197 replied to all 4 of the 4 pings

 

Purtroppo sta diventando sempre più comune che le reti blocchino i pacchetti di ping, o che gli host li ignorino, si può anche dire a STCP di ignorarli (a partire da 15.3, 16.2 e 17x). Se non si può usare il ping, si può usare packet_monitor per calcolare quanto tempo ci vuole per ottenere una risposta ad una richiesta di connessione. Per esempio avviare packet_monitor con il comando "start_process 'packet_monitor -numeric -time_stamp -filter -host A.B.C.D -port NNN' -privileged”. Poi digitare il comando "telnet A.B.C.D NNN”. Dovreste fare diversi collegamenti e ottenere una media. Notate che mi sto collegando ad una porta non utilizzata dell'host remoto. Questo riduce il numero di pacchetti nella traccia, ma se un firewall sta bloccando la porta potrebbe essere necessario utilizzare una porta attiva.

 

start_process 'packet_monitor -numeric -time_stamp -filter -host 192.168.200.197
+ -port 6666' -privileged
ready 09:12:42
telnet 192.168.200.197 6666
Trying...
telnet: Unable to connect to remote host: The connection was refused.
ready 09:12:53
telnet 192.168.200.197 6666
Trying...
telnet: Unable to connect to remote host: The connection was refused.
ready 09:12:56
telnet 192.168.200.197 6666
Trying...
telnet: Unable to connect to remote host: The connection was refused.
ready 09:12:58
telnet 192.168.200.197 6666
Trying...
telnet: Unable to connect to remote host: The connection was refused.
ready 09:12:58
stop_process packet_monitor -no_ask
Stopping Noah_Davids.CAC (packet_monitor).
ready 09:13:07
d packet_monitor.out
%phx_vos#m16_mas>SysAdmin>Noah_Davids>packet_monitor.out 09-11-13 09:13:17 mst
Noah_Davids.CAC logged in on %phx_vos#m16 at 09-11-13 09:12:42 mst.
packet_monitor -numeric -time_stamp -filter -host 192.168.200.197 -port 6666
***********************************************************
WARNING: failure to specify a specific interface will cause
packet_monitor to bind to ALL interfaces on the module,
greatly increasing the amount of Streams memory used!!!
***********************************************************
dir                                                 icmp type
+     tcp
hh:mm:ss.ttt    len proto source             destination         src port dst p
+ort type
9:12:52.984 T 0004 TCP 172.16.77.128       192.168.200.197           62515
+ 6666 S
9:12:53.067 R 0000 TCP 192.168.200.197     172.16.77.128              6666
+ 62515 RA
9:12:56.643 T 0004 TCP 172.16.77.128       192.168.200.197           62516
+ 6666 S
9:12:56.724 R 0000 TCP 192.168.200.197     172.16.77.128              6666
+ 62516 RA
9:12:58.003 T 0004 TCP 172.16.77.128       192.168.200.197           62517
+ 6666 S
9:12:58.086 R 0000 TCP 192.168.200.197     172.16.77.128              6666
+ 62517 RA
9:12:58.805 T 0004 TCP 172.16.77.128       192.168.200.197           62518
+ 6666 S
9:12:58.887 R 0000 TCP 192.168.200.197     172.16.77.128              6666
+ 62518 RA
ready 09:13:07
Process finished.
Terminating Noah_Davids.CAC (packet_monitor). Process stopped by Noah_Davids.CA
+C.

 

Latency times:   58.887 - 58.805 = 0.082 == 82ms
58.086 - 58.003 = 0.083 == 83ms
56.724 - 56.643 = 0.081 == 81ms
53.067 - 52.984 = 0.083 == 83ms

È 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.

stcp_tping 192.168.200.197 23 1
tping 192.168.200.197 23 1
Success/Tries=Percent    min/average/max success times
1/1=100.000%             83.284/83.284/83.284     Connection in 83.284 ms
2/2=100.000%             81.697/82.490/83.284     Connection in 81.697 ms
3/3=100.000%             80.858/81.946/83.284     Connection in 80.858 ms
4/4=100.000%             80.858/81.895/83.284     Connection in 81.743 ms
^C

 

Come si può stimare la latenza se non si dispone già di sistemi di misurazione? Il modo più semplice è trovare un sistema nella stessa area geografica e misurarne la latenza. Questo vi darà una stima molto approssimativa. Mi piace usare i college e le università perché so dove si trovano e le probabilità sono che ospitino i loro sistemi nel campus e, almeno le università più grandi, probabilmente hanno collegamenti Internet ad alta larghezza di banda. Il sito web http://www.utexas.edu/world/univ/state/ elenca i siti web di molte università per stato. Il sito web http://www.bulter.nl/universities/ elenca i siti web delle università di tutto il mondo per paese. Tenete presente che potrebbe esserci una differenza significativa tra la comunicazione su una VPN aziendale e su Internet.

 

Come si può risolvere il problema? Probabilmente non si può. Potreste avere un certo controllo sulla larghezza di banda di alcuni dei collegamenti e forse su alcuni dispositivi di rete, ma di certo non avete alcun controllo sulla distanza. Quello che si può fare è cambiare l'applicazione in modo che sia meno sensibile alla latenza riducendo il numero di giri richiesti.

 

Se si utilizza OSL per spostare file di grandi dimensioni su lunghe distanze, posso solo dire di no. A seconda del tipo di file si può essere in grado di utilizzare FTP, o SFTP o SCP. In caso contrario il sito ftp Stratus ha un'applicazione chiamata tcp_save(ftp://ftp.stratus.com/vos/network/tcp_save.save.evf.gz) che permette di copiare efficacemente un file via TCP senza usare OSL. Richiede una certa configurazione, ma può ridurre significativamente il tempo di copia di file di grandi dimensioni.

 

© 2024 Stratus Technologies.