Quando rappresenti graficamente la velocità effettiva nel tempo man mano che un'altra variabile viene modificata, in genere la velocità effettiva aumenta fino a raggiungere un punto di esaurimento delle risorse.
La figura seguente mostra un tipico grafico di scalabilità della velocità effettiva. Man mano che il numero di client aumenta, il carico di lavoro e la velocità effettiva aumentano fino a quando tutte le risorse non vengono esaurite.
Idealmente, quando raddoppi il carico sul sistema, anche la velocità effettiva dovrebbe raddoppiare. In pratica, si verificherà un conflitto sulle risorse che porterà a aumenti di velocità effettiva più piccoli. A un certo punto, l'esaurimento o il conflitto delle risorse farà sì che la velocità effettiva si appiattisca o addirittura diminuisca. Se stai ottimizzando la velocità effettiva, questo è un punto chiave da identificare, in quanto indirizza i tuoi sforzi verso la regolazione dell'applicazione o del sistema di database per migliorare la velocità effettiva.
I motivi tipici per cui la velocità effettiva si stabilizza o diminuisce includono i seguenti:
- Esaurimento delle risorse della CPU sul server del database
- Esaurimento delle risorse della CPU sul client, quindi al server del database non vengono inviati altri carichi di lavoro
- Conflitto di blocco del database
- Tempo di attesa I/O quando i dati superano le dimensioni del pool di buffer di Postgres
- Tempo di attesa I/O dovuto all'utilizzo del motore di archiviazione
- Colli di bottiglia della larghezza di banda della rete che restituiscono i dati al client
La latenza e la velocità effettiva sono inversamente proporzionali. Man mano che la latenza aumenta, la velocità effettiva diminuisce. Intuitivamente, questo ha senso. Quando inizia a materializzarsi un collo di bottiglia, le operazioni iniziano a richiedere più tempo e il sistema esegue meno operazioni al secondo.
Il grafico di scalabilità della latenza mostra come cambia la latenza man mano che aumenta il carico su un sistema. La latenza rimane relativamente costante fino a quando non si verifica un attrito dovuto al conflitto di risorse. Il punto di inflessione di questa curva corrisponde in genere all'appiattimento della curva di velocità effettiva nel grafico di scalabilità della velocità effettiva.
Un altro modo utile per valutare la latenza è un istogramma. In questa rappresentazione, raggruppiamo le latenze in bucket e contiamo quante richieste rientrano in ogni bucket.
Questo istogramma di latenza mostra la maggior parte delle richieste con una latenza inferiore a 100 millisecondi e le latenze superiori a 100 millisecondi. Comprendere la causa delle richieste con una latenza più lunga può aiutare a spiegare le variazioni del rendimento dell'applicazione. Le cause della lunga coda di latenze aumentate corrispondono alle latenze aumentate visualizzate nel tipico grafico di scalabilità della latenza e all'appiattimento del grafico della velocità effettiva.
L'istogramma di latenza è più utile quando in un'applicazione sono presenti più modalità. Una modalità è un insieme normale di condizioni operative. Ad esempio, la maggior parte delle volte l'applicazione accede alle pagine presenti nella cache del buffer. La maggior parte delle volte, l'applicazione aggiorna le righe esistenti, ma potrebbero esistere più modalità. A volte, l'applicazione recupera le pagine dallo spazio di archiviazione, inserisce nuove righe o riscontra un conflitto di blocco.
Quando un'applicazione incontra queste diverse modalità di funzionamento nel tempo, l'istogramma di latenza mostra queste più modalità.
Questa figura mostra un tipico istogramma bimodale in cui la maggior parte delle richieste viene gestita in meno di 100 millisecondi, ma esiste un altro cluster di richieste che richiedono 401-500 millisecondi. Comprendere la causa di questa seconda modalità può contribuire a migliorare il rendimento dell'applicazione. Possono esistere anche più di due modalità.
La seconda modalità potrebbe essere dovuta a normali operazioni di database, infrastrutture e topologie eterogenee o al comportamento dell'applicazione. Ecco alcuni esempi da considerare:
- La maggior parte degli accessi ai dati proviene dal pool di buffer di PostgreSQL, ma alcuni provengono dallo spazio di archiviazione
- Differenze nelle latenze di rete per alcuni client al server del database
- Logica dell'applicazione che esegue operazioni diverse a seconda dell'input o dell'ora del giorno
- Conflitto di blocco sporadico
- Picchi nell'attività del client