Quando esegui il benchmarking del rendimento, definisci cosa ti aspetti di imparare dal test prima di iniziare. Ad esempio:
- Qual è la velocità effettiva massima che il sistema può raggiungere?
- Quanto tempo richiede una query o un carico di lavoro specifico?
- Come cambiano le prestazioni all'aumentare della quantità di dati?
- Come si confronta il rendimento di due sistemi diversi?
- Di quanto il motore colonnare riduce il tempo di risposta delle prestazioni delle query?
- Quanto carico può gestire un database prima che debba prendere in considerazione l'upgrade a una macchina più potente?
Comprendere gli obiettivi dello studio sul rendimento ti consente di sapere quale benchmark eseguire, quale ambiente è richiesto e quali metriche devi raccogliere.
Ripetibilità
Per trarre conclusioni dai test delle prestazioni, i risultati devono essere ripetibili. Se i risultati del test presentano un'ampia variazione, sarà difficile valutare l'impatto delle modifiche apportate all'applicazione o alla configurazione del sistema. L'esecuzione dei test più volte o per periodi di tempo più lunghi per fornire più dati può contribuire a ridurre l'importo della variazione.
Idealmente, i test delle prestazioni devono essere eseguiti su sistemi isolati da altri sistemi. L'esecuzione in un ambiente in cui i sistemi esterni possono influire sulle prestazioni dell'applicazione può portare a conclusioni errate. L'isolamento completo spesso non è possibile quando viene eseguito in un ambiente cloud multi-tenant, quindi devi aspettarti una maggiore variabilità nei risultati
Parte della ripetibilità consiste nel garantire che il workload di test rimanga lo stesso tra le esecuzioni. Un po' di casualità nell'input di un test è accettabile, a condizione che non causi un comportamento dell'applicazione significativamente diverso. Se l'input del client generato in modo casuale modifica il mix di letture e scritture da un'esecuzione all'altra, il rendimento varierà in modo significativo.
Dimensioni del database, memorizzazione nella cache e pattern di I/O
Assicurati che la quantità di dati con cui esegui i test sia rappresentativa della tua applicazione. L'esecuzione di test con una piccola quantità di dati quando hai centinaia di gigabyte o terabyte di dati probabilmente non fornirà una rappresentazione fedele delle prestazioni della tua applicazione. Anche le dimensioni del set di dati influiscono sulle scelte effettuate dall'ottimizzatore delle query. Le query sulle tabelle di test di piccole dimensioni potrebbero utilizzare scansioni delle tabelle che offrono prestazioni scarse su scale più grandi e non identificherai gli indici mancanti in questa configurazione.
Cerca di replicare i pattern I/O della tua applicazione. Il rapporto tra letture e scritture è importante per il profilo delle prestazioni della tua applicazione.
Durata benchmark
In un sistema complesso, vengono mantenute molte informazioni sullo stato durante l'esecuzione del sistema: vengono stabilite connessioni al database, le cache vengono popolate, vengono generati processi e thread. All'inizio di un test delle prestazioni, l'inizializzazione di questi componenti potrebbe utilizzare le risorse di sistema e influire negativamente sulle prestazioni misurate se il runtime del workload è troppo breve.
Ti consigliamo di eseguire i test delle prestazioni per almeno 20 minuti per ridurre al minimo gli effetti del riscaldamento del sistema. Misura il rendimento durante uno stato stabile dopo l'avvio e per un periodo di tempo sufficiente a garantire che siano inclusi tutti gli aspetti delle operazioni del database. Ad esempio, i checkpoint del database sono una funzionalità fondamentale dei sistemi di database e possono avere un impatto significativo sulle prestazioni. L'esecuzione di un breve benchmark che viene completato prima dell'intervallo di checkpoint nasconde questo importante fattore nel comportamento dell'applicazione.
Test metodici
Quando regoli il rendimento, modifica una sola variabile alla volta. Se modifichi più variabili tra un'esecuzione e l'altra, non potrai isolare la variabile che ha migliorato il rendimento. Infatti, più modifiche possono compensarsi a vicenda, quindi non vedrai il vantaggio di una modifica appropriata. Se il server di database è sovrautilizzato, prova a passare a una macchina con più vCPU mantenendo costante il carico. Se il server di database è sottoutilizzato, prova ad aumentare il carico mantenendo costante la configurazione della CPU.
Topologia di rete e latenze
La topologia di rete del sistema può influire sui risultati del test delle prestazioni. La latenza tra le zone varia. Quando esegui test delle prestazioni, assicurarti che il client e il cluster di database si trovino nella stessa zona riduce al minimo la latenza di rete e offre le migliori prestazioni, soprattutto per le applicazioni con transazioni brevi e ad alto throughput, poiché la latenza di rete può essere una componente importante del tempo di risposta complessivo della transazione.
Quando confronti il rendimento di due sistemi diversi, assicurati che la topologia di rete sia la stessa per entrambi. Tieni presente che la variabilità della latenza di rete non può essere eliminata completamente. Anche all'interno della stessa zona possono esserci differenze di latenza dovute alle topologie di rete sottostanti.
Quando esegui il deployment dell'applicazione, potresti voler comprendere meglio l'impatto delle latenze tra zone prendendo in considerazione una tipica applicazione web ad alto volume. L'applicazione ha un bilanciatore del carico che invia richieste a più server web di cui è stato eseguito il deployment in più zone per garantire l'alta disponibilità. Le latenze possono variare a seconda del server web che elabora una richiesta a causa delle differenze di latenza tra le zone.
La seguente figura mostra l'architettura tipica di un'applicazione web che utilizza AlloyDB Omni. Le richieste dei client vengono gestite da un bilanciatore del carico, che inoltra ogni richiesta a uno dei tanti server web. Tutti i server web sono connessi ad AlloyDB Omni. Alcuni server si trovano in una zona diversa da quella in cui è in esecuzione AlloyDB Omni e riscontreranno latenze più elevate quando effettuano richieste di database.
Monitoraggio delle risorse
Per ottimizzare le prestazioni del sistema di database, devi monitorare l'utilizzo delle risorse sia del sistema di database sia dei sistemi client che lo utilizzano. Monitorando entrambi i sistemi, puoi assicurarti che i sistemi client forniscano un workload sufficiente per ottenere misurazioni significative nel sistema di database. Il monitoraggio dell'utilizzo delle risorse del sistema che stai testando è fondamentale. È altrettanto importante monitorare l'utilizzo delle risorse dei sistemi client che utilizzi per gestire il workload. Ad esempio, se vuoi determinare il numero massimo di client supportati dal tuo sistema di database prima che esaurisca le risorse CPU, avrai bisogno di un numero sufficiente di sistemi client per generare il carico di lavoro necessario per utilizzare tutte le risorse CPU nel sistema di database. Non potrai utilizzare il sistema di database in modo efficace se le macchine client che generano il carico non dispongono di una CPU sufficiente.
Test di scalabilità
Il test di scalabilità è un altro aspetto del test delle prestazioni. La scalabilità si riferisce al modo in cui le metriche sul rendimento cambiano al variare di una caratteristica di un workload. Alcuni esempi di studi sulla scalabilità includono:
- In che modo un aumento del numero di richieste simultanee modifica il throughput e i tempi di risposta?
- In che modo un aumento delle dimensioni del database modifica la velocità effettiva e i tempi di risposta?
I test di scalabilità consistono in più esecuzioni di un carico di lavoro in cui una singola dimensione varia tra le esecuzioni e vengono raccolte e tracciate una o più metriche. Questo tipo di test fornisce informazioni sulle strozzature esistenti nel sistema, sul carico che il sistema può gestire con una configurazione specifica, sul carico massimo che un sistema può supportare e sul comportamento del sistema quando il carico aumenta oltre questi livelli.
Considerazioni sulle dimensioni della macchina
AlloyDB Omni introduce molte nuove funzionalità in Postgres per migliorare l'affidabilità e la disponibilità del database. Il monitoraggio necessario per eseguire questa operazione utilizza risorse sulla macchina che esegue AlloyDB Omni. Le macchine di dimensioni molto ridotte hanno risorse di memoria e CPU limitate fin dall'inizio, pertanto per il benchmarking consigliamo di utilizzare macchine con almeno quattro vCPU.