Ottimizzazione delle prestazioni di un'applicazione distribuita

  • Articolo

In questa serie vengono illustrati diversi scenari di applicazioni cloud, mostrando come un team di sviluppo ha usato i test di carico e le metriche per diagnosticare i problemi di prestazioni. Questi articoli sono basati su test di carico effettivi eseguiti durante lo sviluppo di applicazioni di esempio. Il codice per ogni scenario è disponibile in GitHub.

Scenari:

Cosa sono le prestazioni?

Le prestazioni vengono in genere misurate in termini di velocità effettiva, tempo di risposta e disponibilità. Gli obiettivi di prestazioni devono essere basati sulle operazioni aziendali. Le attività rivolte ai clienti possono avere requisiti più rigorosi rispetto a quelle operative, ad esempio la generazione di report.

Definire un obiettivo del livello di servizio che stabilisca gli obiettivi di prestazioni per ogni carico di lavoro. Questo obiettivo viene in genere raggiunto suddividendo un obiettivo di prestazioni in un set di indicatori di prestazioni chiave (KPI), ad esempio:

  • Latenza o tempo di risposta di richieste specifiche
  • Il numero di richieste eseguite al secondo
  • La frequenza con cui il sistema genera eccezioni.

Gli obiettivi di prestazioni devono includere in modo esplicito un carico di destinazione. Inoltre, non tutti gli utenti ricevono esattamente lo stesso livello di prestazioni, anche quando accedono contemporaneamente al sistema ed eseguono lo stesso lavoro. Pertanto, un obiettivo del livello di servizio deve essere definito in termini di percentili.

Un esempio di SLO per potrebbe essere: "Le richieste client hanno una risposta entro 500 ms @ P90, con caricamenti fino a 25 K richieste al secondo".

Problemi di ottimizzazione delle prestazioni di un sistema distribuito

Può risultare particolarmente difficile diagnosticare i problemi di prestazioni in un'applicazione distribuita. Alcuni di questi problemi sono:

  • Una singola transazione o operazione aziendale coinvolge in genere più componenti del sistema. Può essere difficile ottenere una visualizzazione olistica completa di una singola operazione.

  • L'utilizzo delle risorse è distribuito tra più nodi. Per ottenere una visualizzazione coerente, è necessario aggregare i log e le metriche in un'unica posizione.

  • Il cloud offre scalabilità elastica. La scalabilità automatica è una tecnica importante per la gestione dei picchi di carico, ma può anche mascherare problemi sottostanti. Inoltre, può essere difficile capire quali componenti devono essere ridimensionati e quando.

  • I carichi di lavoro spesso non vengono ridimensionati tra core o thread. È importante comprendere i requisiti dei carichi di lavoro e esaminare dimensioni ottimizzate migliori. Alcune dimensioni offrono core vincolati e iperthreading disabilitato per migliorare i carichi di lavoro con licenza per core singolo e per core.

  • Gli errori a catena possono generare errori a monte del problema radice. Di conseguenza, il primo segnale del problema può comparire in un componente diverso rispetto a quello della causa radice.

Procedure consigliate generali

L'ottimizzazione delle prestazioni è sia un'arte che una scienza, ma può essere resa maggiormente scientifica adottando un approccio sistematico. Ecco alcune procedure consigliate:

  • Abilitare la telemetria per raccogliere le metriche. Instrumentare il codice. Seguire le procedure consigliate per il monitoraggio. Usare tracce correlate in modo da visualizzare tutti i passaggi di una transazione.

  • Monitorare i 90/95/99 percentili, non solo la media. La media può mascherare outlier. Anche la frequenza di campionamento per le metriche è importante. Se la frequenza di campionamento è troppo bassa, può nascondere picchi o outlier che potrebbero indicare problemi.

  • Affrontare un collo di bottiglia alla volta. Formulare un'ipotesi e testarla cambiando una variabile alla volta. La rimozione di un collo di bottiglia consente spesso di rilevarne un altro più a monte o a valle.

  • Gli errori e la ripetizione di tentativi possono avere un notevole impatto sulle prestazioni. Se si noterà che i servizi back-end limitano il sistema, aumentare il numero di istanze o provare a ottimizzare l'utilizzo, ad esempio ottimizzando le query del database.

  • Cercare antipattern comuni delle prestazioni.

  • Verificare se esistono opportunità per la parallelizzazione. Due cause comuni dei colli di bottiglia sono le code di messaggi e i database. In entrambi i casi, il partizionamento orizzontale può risultare utile. Per altre informazioni, vedere Partizionamento orizzontale, verticale e funzionale dei dati. Cercare le partizioni ad accesso frequente che potrebbero indicare carichi di lettura o scrittura sbilanciati.

Passaggi successivi

Leggere gli scenari di ottimizzazione delle prestazioni