Come analizzare i colli di bottiglia
In questo argomento viene descritto il processo consigliato per analizzare i colli di bottiglia.
Origine del problema
L'origine del problema può essere collegata all'hardware o al software. Quando le risorse sono sottoutilizzate, si tratta in genere di un'indicazione di presenza di un collo di bottiglia in qualche punto del sistema. I colli di bottiglia possono essere dovuti a limitazioni dell'hardware, a configurazioni software inefficienti o a entrambe queste cause.
L'identificazione dei colli di bottiglia costituisce un processo incrementale in cui la risoluzione di un collo di bottiglia può portare all'individuazione di quello successivo. Le tecniche per la loro identificazione e risoluzione sono l'obiettivo di questo argomento. È possibile che un sistema funzioni in condizioni di picco per brevi periodi di tempo. Tuttavia, in termini di velocità effettiva sostenibile, le elaborazioni possono avvenire solo alla velocità del componente con le prestazioni più lente.
Approccio seriale
I colli di bottiglia possono verificarsi agli endpoint (ingresso/uscita) del sistema o in un punto centrale (orchestrazione/database). Una volta isolata la posizione del collo di bottiglia, sarà possibile adottare un approccio strutturato per identificarne l'origine. Dopo la risoluzione dei colli di bottiglia, è fondamentale misurare di nuovo le prestazioni per essere certi che non sia stato introdotto un nuovo collo di bottiglia in qualche altro punto del sistema lungo la linea.
È consigliabile eseguire il processo di identificazione e correzione dei colli di bottiglia in modo seriale, variando un solo parametro alla volta e misurando le prestazioni per verificare l'impatto di tale singola modifica. Se si varia più di un parametro alla volta, l'effetto della modifica potrebbe risultare nascosto.
Ad esempio, la modifica del parametro 1 potrebbe migliorare le prestazioni, ma la modifica del parametro 2 unitamente a quella del parametro 1 potrebbe avere un effetto negativo che annulla i benefici della modifica del parametro 1, con un conseguente effetto zero. Tuttavia, il risultato è un falso negativo per l'effetto della variazione del parametro 1 e un falso positivo per l'effetto della variazione del parametro 2.
Coerenza dei test
Per convalidare l'effetto della modifica, è indispensabile misurare le caratteristiche delle prestazioni dopo la modifica delle impostazioni.
Hardware: è importante usare hardware coerente, poiché l'hardware può visualizzare un comportamento incoerente, generando risultati fuorvianti, ad esempio non usare un portatile.
Durata esecuzione test: è anche importante misurare le prestazioni per un periodo minimo fisso per garantire che i risultati siano effettivamente sostenibili e non semplicemente picchi. Un altro motivo per eseguire i test su periodi più estesi è di garantire al sistema il completamento del periodo iniziale di riscaldamento/preparazione in cui tutte le cache vengono popolate, alle tabelle di database il raggiungimento dei conteggi previsti e alla limitazione delle richieste il tempo sufficiente per avviare e regolare la velocità effettiva una volta raggiunte le soglie predefinite. L'applicazione di questo approccio consentirà di individuare la velocità effettiva sostenibile ottimale.
Parametri di test: è inoltre imperativo non variare i parametri di test dall'esecuzione del test all'esecuzione dei test. Ad esempio, variando la complessità di una mappa e/o le dimensioni di un documento, si possono produrre risultati di velocità effettiva e di latenza differenti.
Stato pulito: una volta completato un test, è importante pulire tutto lo stato prima di eseguire l'esecuzione del test successivo. Ad esempio, i dati cronologici possono accumularsi nel database con conseguenze sulla velocità effettiva in fase di esecuzione. Mediante il riciclo delle istanze del servizio è possibile rilasciare risorse memorizzate nella cache, ad esempio memoria, connessioni di database e thread.
Aspettative: velocità effettiva e latenza
È ragionevole aspettarsi una certa velocità effettiva e/o latenza dal sistema distribuito, ma è impossibile tentare di avere insieme velocità effettiva elevata e latenza bassa. È tuttavia realistico aspettarsi una velocità effettiva ottimale con una latenza ragionevole. Con l'aumentare della velocità effettiva, il sistema viene sottoposto a un utilizzo intensivo maggiore (maggiore utilizzo della CPU, maggiore contesa dell'I/O del disco, pressione sulla memoria, maggiore contesa dei blocchi), con un possibile impatto negativo sulla latenza. Per individuare la capacità ottimale di un sistema, è fondamentale identificare e risolvere tutti i colli di bottiglia.
I colli di bottiglia possono essere causati da dati legacy (istanze completate) che risiedono nel database non eliminati. Quando si verifica questa situazione, le prestazioni possono peggiorare. Dare al sistema il tempo sufficiente per svuotarsi può contribuire alla risoluzione del problema. È tuttavia importante individuare la causa dell'accumulo di backlog e risolvere il problema.
Per individuare la causa del backlog, è importante analizzare i dati cronologici e monitorare i contatori di Performance Monitor per individuare i modelli di utilizzo ed eseguire la diagnosi dell'origine del backlog. Si tratta di una situazione comune quando grandi volumi di dati vengono elaborati in batch durante la notte. L'individuazione della capacità del sistema e della sua possibilità di recupero da un backlog può essere utile quando si valutano i requisiti hardware per gestire scenari di superamento dei limiti consentiti e la quantità di spazio di buffer da ospitare in un sistema per gestire picchi imprevisti di velocità effettiva.
La regolazione del sistema per una velocità effettiva sostenibile ottimale richiede una conoscenza approfondita dell'applicazione distribuita, dei punti di forza e di debolezza del sistema e dei modelli di utilizzo dello scenario specifico. Il solo modo per individuare i colli di bottiglia e prevedere con certezza la velocità effettiva sostenibile ottimale è attraverso test completi su una topologia che corrisponda strettamente a quella che sarà utilizzata in produzione.
In altri argomenti di questa sezione viene illustrato il processo di definizione di tale topologia e vengono fornite indicazioni su come risolvere i colli di bottiglia ed evitarli.
Scalabilità
I colli di bottiglia possono verificarsi in vari punti della topologia distribuita. Alcuni possono essere risolti con un aggiornamento dell'hardware, che può avvenire mediante scalabilità verticale (più CPU, memoria o cache) o scalabilità verticale (server aggiuntivi) a seconda del tipo di collo di bottiglia riscontrato e dell'applicazione che viene configurata. Di seguito vengono fornite indicazioni su come modificare le topologie di distribuzione hardware in base ai colli di bottiglia riscontrati. Un'applicazione deve essere compilata da zero per poter sfruttare i vantaggi dell'aumento o dell'aumento delle prestazioni. Per esempio:
La scalabilità verticale di un server con CPU e/o memoria aggiuntive potrebbe non risolvere il problema se l'applicazione è serializzata e dipende da un singolo thread di esecuzione.
La scalabilità orizzontale di un sistema con server aggiuntivi potrebbe non risultare utile se i server aggiuntivi aggiungono semplicemente contesa su una risorsa comune che non può essere distribuita con scalabilità orizzontale. La scalabilità orizzontale fornisce tuttavia altri vantaggi. La distribuzione di due server a doppio processore anziché di un server a quattro processori fornisce un server ridondante con la duplice funzione di scalabilità per la gestione di maggiore velocità e di una topologia a elevata disponibilità.