Quando esegui il benchmarking delle prestazioni, definisci cosa ti aspetti di imparare dal test prima di iniziare. Ad esempio:
- Qual è il throughput massimo che il sistema può raggiungere?
- Quanto tempo richiede una query o un carico di lavoro specifico?
- Come cambiano le prestazioni man mano che aumenta la quantità di dati?
- Come si confrontano le prestazioni 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 di dover prendere in considerazione l'upgrade a una macchina più potente?
La comprensione degli obiettivi dello studio delle prestazioni ti consente di scegliere il benchmark da eseguire, l'ambiente richiesto e le metriche da raccogliere.
Ripetibilità
Per trarre conclusioni dai test delle prestazioni, i risultati dei test devono essere ripetibili. Se i risultati dei 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 la quantità di 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 si esegue in un ambiente cloud multi-tenant, quindi devi aspettarti una maggiore variabilità nei risultati.
Parte della ripetibilità consiste nel garantire che il carico di lavoro di test rimanga lo stesso tra le esecuzioni. È accettabile una certa casualità nell'input di un test, 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, le prestazioni varieranno in modo significativo.
Dimensioni del database, memorizzazione nella cache e pattern di I/O
Assicurati che la quantità di dati con cui stai eseguendo 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 darà una rappresentazione fedele del rendimento della tua applicazione. Le dimensioni del set di dati influenzano anche le scelte dell'ottimizzatore delle query. Le query sulle tabelle di test di piccole dimensioni potrebbero utilizzare scansioni di tabelle che offrono prestazioni scadenti su scale più grandi e non identificherai gli indici mancanti in questa configurazione.
Cerca di replicare i pattern di I/O della tua applicazione. Il rapporto tra letture e scritture è importante per il profilo di prestazioni della tua applicazione.
Durata del 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 carico di lavoro è 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 le prestazioni durante uno stato stazionario 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 benchmark breve che viene completato prima dell'intervallo di checkpoint nasconde questo fattore importante nel comportamento dell'applicazione.
Test metodici
Quando ottimizzi le prestazioni, modifica una sola variabile alla volta. Se modifichi più variabili tra le esecuzioni, non potrai isolare la variabile che ha migliorato le prestazioni. 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 dei test delle prestazioni. La latenza tra le zone è diversa. Quando esegui i test delle prestazioni, assicurati che il client e il cluster di database si trovino nella stessa zona per ridurre al minimo la latenza di rete e ottenere le prestazioni migliori, 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 delle transazioni.
Quando confronti le prestazioni di due sistemi diversi, assicurati che la topologia di rete sia la stessa per entrambi i sistemi. 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 le 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 un'alta affidabilità. Le latenze potrebbero variare a seconda del server web che elabora una richiesta a causa delle differenze di latenza tra le zone.
La figura seguente 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 un server web tra molti. 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 carico di lavoro 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 carico di lavoro. Ad esempio, se vuoi determinare il numero massimo di client che il tuo sistema di database può supportare prima di esaurire le risorse della CPU, avrai bisogno di sistemi client sufficienti per generare il carico di lavoro necessario per utilizzare tutte le risorse della CPU nel sistema di database. Non potrai gestire il sistema di database in modo sufficiente se le macchine client che generano il carico non hanno una CPU sufficiente.
Test di scalabilità
I test di scalabilità sono un altro aspetto dei test delle prestazioni. La scalabilità si riferisce a come cambiano le metriche delle prestazioni al variare di una caratteristica di un carico di lavoro. Di seguito sono riportati alcuni esempi di studi di scalabilità:
- 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 il throughput e i tempi di risposta?
I test di scalabilità consistono in più esecuzioni di un carico di lavoro in cui una singola dimensione viene variata tra le esecuzioni e vengono raccolte e tracciate una o più metriche. Questo tipo di test fornisce informazioni sulle decisioni relative ai colli di bottiglia esistenti nel sistema, al carico che il sistema può gestire con una configurazione specifica, al carico massimo che un sistema può supportare e al 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 questa operazione utilizza le risorse della macchina su cui è in esecuzione AlloyDB Omni. Nelle dimensioni delle macchine molto piccole, le risorse di memoria e CPU sono limitate, quindi per il benchmarking consigliamo di utilizzare dimensioni delle macchine con almeno quattro vCPU.