Questo documento descrive come interpretare i risultati sul rendimento in AlloyDB Omni su una VM. Questo documento presuppone che tu abbia familiarità con PostgreSQL.
Quando rappresenti il throughput nel tempo man mano che un'altra variabile viene modificata, in genere il throughput aumenta fino a raggiungere un punto di esaurimento delle risorse.
La figura seguente mostra un tipico grafico di scalabilità della throughput. Con l'aumento del numero di client, il carico di lavoro e il throughput aumentano fino a quando non vengono esaurite tutte le risorse.
Idealmente, quando raddoppi il carico sul sistema, dovrebbe raddoppiare anche la velocità in uscita. In pratica, si verificherà una contesa per le risorse che comporterà aumenti minori del throughput. A un certo punto, l'esaurimento delle risorse o la contesa causeranno un appiattimento o addirittura una diminuzione del throughput. Se stai ottimizzando per il throughput, questo è un punto chiave da identificare perché ti aiuta a capire dove ottimizzare il sistema di database o dell'applicazione per migliorare il throughput.
Ecco alcuni motivi comuni per cui il throughput si stabilizza o diminuisce:
- Esaurimento delle risorse della CPU sul server del database
- Esaurimento delle risorse della CPU sul client, pertanto al server del database non viene inviato altro lavoro
- Conflitto di blocco del database
- Tempo di attesa I/O quando i dati superano le dimensioni del pool di buffer Postgres
- Tempo di attesa I/O dovuto all'utilizzo del motore di archiviazione
- Bottleneck della larghezza di banda della rete che restituisce i dati al client
La latenza e il throughput sono inversamente proporzionali. Con l'aumento della latenza, il throughput diminuisce. Intuitivamente, ha senso. Quando si verifica 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 la latenza cambia con l'aumento del carico su un sistema. La latenza rimane relativamente costante finché non si verificano problemi a causa della contesa delle risorse. Il punto di flesso di questa curva corrisponde in genere all'appiattimento della curva di throughput nel grafico di scalabilità del throughput.
Un altro modo utile per valutare la latenza è sotto forma di istogramma. In questa rappresentazione, raggruppiamo le latenze in bucket e contiamo quante richieste rientrano in ogni bucket.
Questo istogramma delle latenze mostra che la maggior parte delle richieste ha una latenza inferiore a 100 millisecondi e le latenze superiori a 100 millisecondi. Comprendere la causa delle richieste con code di latenza più lunghe può aiutare a spiegare le variazioni del rendimento dell'applicazione osservate. Le cause della coda lunga delle latenze aumentate corrispondono alle latenze aumentate osservate nel grafico di scalabilità della latenza tipico e all'appiattimento del grafico della produttività.
L'istogramma della latenza è più utile quando in un'applicazione sono presenti più modalità. Una modalità è un normale insieme di condizioni di funzionamento. Ad esempio, la maggior parte del tempo l'applicazione accede alle pagine nella cache del buffer. La maggior parte delle volte l'applicazione aggiorna le righe esistenti, ma potrebbero essere presenti più modalità. A volte l'applicazione recupera pagine dallo spazio di archiviazione, inserisce nuove righe o presenta conflitti di blocco.
Quando un'applicazione incontra queste diverse modalità di funzionamento nel tempo, l'istogramma della latenza mostra queste più modalità.
Questa figura mostra un tipico istogramma bimodale in cui la maggior parte delle richieste viene soddisfatta in meno di 100 millisecondi, ma è presente un altro cluster di richieste che richiedono 401-500 millisecondi. Comprendere la causa di questa seconda modalità può contribuire a migliorare le prestazioni dell'applicazione. Possono essere presenti anche più di due modalità.
La seconda modalità potrebbe essere dovuta a normali operazioni del database, a un'infrastruttura e a una topologia eterogenee o al comportamento dell'applicazione. Ecco alcuni esempi da prendere in considerazione:
- La maggior parte degli accessi ai dati proviene dal pool di buffer PostgreSQL, ma alcuni provengono dallo spazio di archiviazione
- Differenze nelle latenze di rete per alcuni client rispetto al server di database
- Logica di applicazione che esegue operazioni diverse a seconda dell'input o dell'ora del giorno
- Conflitto di blocco sporadico
- Picchi di attività dei client