Ridurre la latenza nelle applicazioni Web: una guida rapida per affrontare i giusti colli di bottiglia

Se sei arrivato qui, probabilmente sai già cos'è la latenza e vuoi agire. Questo testo non ti farà perdere tempo a definire nuovamente il concetto. È una guida pratica per chi ha bisogno di realizzare un'applicazione web più velocemente e vuole farlo nell'ordine giusto, senza spendere settimane in ottimizzazioni che non muovono l'ago.

La regola che organizza tutto ciò che segue è una sola: attaccare prima il collo di bottiglia più grande. La latenza si concentra. In un'applicazione tipica, uno o due passaggi rappresentano la maggior parte dell'attesa. Trovarli e risolverli vale più di decine di piccoli aggiustamenti sparsi qua e là.

Passiamo dalla parte che di solito fa più male a quella che di solito fa meno male. Adatta l'ordine alla tua realtà, ma solo dopo aver misurato.

Inizia misurando, sempre

Saltare questo passaggio è l’errore più costoso. Senza misurazione, stai ottimizzando al buio e la possibilità di fare confusione nel posto sbagliato è alta.

Prima di toccare qualsiasi codice, strumentare la richiesta. È necessario sapere quanto tempo viene trascorso sul server, quanto sull'interrogazione dei dati, quanto sulla rete e quanto sul rendering del browser. [gli strumenti di osservabilità nel backend e gli strumenti di sviluppo del browser forniscono un quadro sufficiente per iniziare.

Guarda anche la distribuzione, non solo la media. La latenza dei casi peggiori, gli utenti nel percentile negativo, è ciò che genera lamentele e abbandono. Un tempo medio accettabile può nascondere una lunga coda di persone sofferenti. Ottimizza tenendo presente questa coda.

Il database è spesso il cattivo

Nella maggior parte delle applicazioni che rallentano nel tempo, il collo di bottiglia risiede nelle query. Vale la pena iniziare da qui.

Il classico sospetto è la query senza un indice adeguato. Man mano che la tabella cresce, una ricerca che era istantanea con un migliaio di record diventa un trascinamento con milioni. Identificare le query lente e aggiungere gli indici giusti è spesso l'ottimizzazione del rendimento più elevata possibile.

Il secondo sospetto è lo schema di molte query in sequenza: l'applicazione cerca in un elenco e, per ciascun elemento, attiva una nuova query. Dieci articoli hanno comportato undici viaggi in banca; cento elementi diventano centouno. Risolvere questo problema recuperando i dati tutti in una volta trasforma una pagina lenta in una pagina veloce senza modificare nient'altro.

La terza è la query che porta troppi dati. Richiedere tutte le colonne quando ne usi tre o inserire migliaia di righe per mostrarne venti, fa perdere tempo su ogni livello. Ordina solo ciò che utilizzerai.

Cache: la scorciatoia più potente e pericolosa

La cache è lo strumento che riduce maggiormente la latenza e introduce i bug più subdoli. Utilizzare con intenzione.

L'idea è semplice: salvare il risultato di un'operazione costosa per non ripeterla. Dati che cambiano poco e vengono letti molto, un catalogo, una configurazione, una pagina pubblica, sono candidati perfetti. L'elaborazione dalla cache elimina la ricerca nel database e gran parte dell'elaborazione.

Il pericolo sta nell'invalidazione: garantire che la cache venga aggiornata quando i dati cambiano. La cache che serve vecchie informazioni genera problemi difficili da diagnosticare, perché il sistema "funziona", è semplicemente sbagliato. Prima di aggiungere la cache, decidi come verrà invalidata. Se non sai come rispondere, non sei ancora pronto per farlo.

Cache a più livelli

C'è più di un posto dove arricciarsi e si sommano. Nel browser è possibile salvare le risorse statiche in modo che non vengano scaricate nuovamente. In una CDN, il contenuto può essere servito da un punto fisicamente vicino all'utente. Sul server potrebbero rimanere in memoria i risultati di operazioni costose. Ogni livello taglia una parte della latenza totale.

Accorciare le distanze e riutilizzare le connessioni

Parte della latenza è pura fisica: la distanza tra l'utente e il server. Non puoi battere la velocità della luce, ma puoi abbreviare il percorso.

Una CDN posiziona copie dei tuoi contenuti vicino a chiunque vi acceda. Per un pubblico brasiliano, servire da punti di presenza nel paese, anziché da un server distante, riduce i tempi di viaggio che nessuna ottimizzazione del codice potrebbe recuperare. Per i contenuti e i media statici, è uno dei migliori rapporti sforzo-vincita.

Anche il riutilizzo delle connessioni consente di risparmiare. L'apertura di una nuova connessione sicura comporta un costo per i viaggi di andata e ritorno attraverso la rete; mantenere attive le connessioni e utilizzare protocolli moderni riduce questo costo ripetuto. Questo è un vantaggio che appare soprattutto sulle pagine che fanno molte richieste.

Scarica il browser

Anche con il server veloce, la schermata appare solo dopo che il browser ha elaborato la risposta. Quest’ultima sezione merita attenzione.

I delinquenti comuni sono noti. JavaScript eccessivo che rallenta il caricamento della pagina. Immagini di grandi dimensioni pubblicate senza compressione o con dimensioni errate. Funzionalità che bloccano il display durante la ricarica. Ridurre e rinviare ciò che non è essenziale alla prima schermata fa sembrare l'applicazione veloce anche quando sta ancora finendo di caricare il resto.

La percezione conta tanto quanto i numeri. Mostrare contenuti utili in anticipo, anche se parziali, fa sentire l'utente veloce. Uno schermo vuoto per due secondi è peggio di uno schermo che mostra immediatamente la struttura e poi la completa.

Anche qui vale la pena applicare la stessa logica proporzionale. Prima di riscrivere un intero componente in nome della performance, conferma che la sezione che intendi attaccare sia quella che appare nella prima schermata. Spesso il vantaggio maggiore deriva dal posticipare il caricamento di qualcosa di secondario, non dal riscrivere la cosa principale.

L'errore di ottimizzare ciò che non fa male

Vale la pena ricordare l'avvertimento che chiude ogni guida onesta alle prestazioni: non ottimizzare l'invisibile. È facile innamorarsi di un elegante pezzo di codice e passare giorni a risparmiare millisecondi che nessuno nota, mentre il vero collo di bottiglia rimane intatto.

Torna sempre alla misurazione. Dopo ogni ottimizzazione, misura nuovamente e conferma che il numero ritenuto dall'utente sia effettivamente migliorato. Se non è migliorato, hai ottimizzato la cosa sbagliata. La performance è un gioco di proporzioni e l’umiltà di misurare è ciò che evita gli sprechi.

Chiusura

Ridurre la latenza non è magia o eroismo tecnico. È un metodo: misurare, trovare il collo di bottiglia più grande, risolverlo, misurare ancora. Database, cache, distanza e browser sono i luoghi in cui si perde maggiormente tempo, e quasi sempre uno di essi concentra il problema.

La velocità è una decisione sul prodotto mascherata da compito ingegneristico. I team che lo trattano metodicamente forniscono applicazioni che rispettano il tempo dell'utente e spendono meno energia per spegnere in seguito i problemi di prestazioni.

Se svolgi questo lavoro adesso, inizia con la misurazione prima di ogni altra cosa. Ci sono altri articoli qui sul blog su architettura, memorizzazione nella cache e scalabilità che approfondiscono ciascuno di questi punti.