Questo documento descrive i consigli per eseguire test delle prestazioni su AlloyDB Omni su una VM. Questo documento presuppone che tu abbia familiarità con PostgreSQL.
Quando esegui il benchmarking del rendimento, definisci cosa ti aspetti di apprendere dal test prima di iniziare. Ad esempio:
- Qual è la velocità effettiva massima che può raggiungere il sistema?
- Quanto tempo richiede una determinata query o un determinato carico di lavoro?
- Come cambia il rendimento con l'aumento della quantità di dati?
- Qual è il rendimento di due sistemi diversi?
- Quanto il motore colonnare riduce il tempo di risposta del rendimento 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 è necessario e quali metriche devi raccogliere.
Ripetibilità
Per trarre conclusioni dai test delle prestazioni, i risultati del test devono essere ripetibili. Se i risultati del test presentano una variazione ampia, sarà difficile valutare l'impatto delle modifiche apportate all'applicazione o alla configurazione del sistema. Eseguire i 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 di prestazioni devono essere eseguiti su sistemi isolati da altri sistemi. L'esecuzione in un ambiente in cui i sistemi esterni possono influire sul rendimento dell'applicazione può portare a trarre conclusioni errate. Spesso non è possibile l'isolamento completo quando l'esecuzione avviene in un ambiente cloud multi-tenant, quindi dovresti aspettarti una maggiore variabilità nei risultati
La ripetibilità prevede anche di garantire che il carico di lavoro del test rimanga invariato tra le esecuzioni. È accettabile una certa casualità nell'input di un test, a condizione che la casualità non causi un comportamento dell'applicazione significativamente diverso. Se l'input del client generato in modo casuale modifica la combinazione di letture e scritture da un'esecuzione all'altra, il rendimento varierà notevolmente.
Dimensioni del database, memorizzazione nella cache e pattern I/O
Assicurati che la quantità di dati con cui stai eseguendo il 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 reale del rendimento della tua applicazione. Le dimensioni del set di dati influiscono anche sulle scelte effettuate dall'ottimizzatore delle query. Le query su piccole tabelle di test potrebbero utilizzare scansioni delle tabelle che offrono prestazioni scadenti su larga scala 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 delle prestazioni dell'applicazione.
Durata del benchmark
In un sistema complesso, vengono mantenute molte informazioni sullo stato durante l'esecuzione del sistema: vengono stabilite connessioni al database, vengono compilate le cache, vengono generati processi e thread. All'inizio di un test delle prestazioni, l'inizializzazione di questi componenti potrebbe occupare risorse di sistema e influire negativamente sul rendimento misurato se il tempo di esecuzione del carico di lavoro è troppo breve.
Ti consigliamo di eseguire i test di prestazioni per almeno 20 minuti per ridurre al minimo gli effetti dell'avvio 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 si completa prima dell'intervallo del checkpoint nasconde questo fattore importante nel comportamento dell'applicazione.
Test metodici
Quando ottimizzi 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 è diversa. Quando esegui test di prestazioni, assicurati che il client e il cluster di database si trovino nella stessa zona per ridurre al minimo la latenza della rete e ottenere le migliori prestazioni, in particolare per le applicazioni con un elevato throughput e transazioni brevi, poiché la latenza della rete può essere un 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 della rete non può essere eliminata completamente, anche all'interno della stessa zona possono esserci differenze di latenza a causa delle topologie di rete sottostanti.
Quando esegui il deployment dell'applicazione, ti consigliamo di comprendere meglio l'impatto delle latenze tra zone prendendo in considerazione una tipica applicazione web ad alto volume. L'applicazione dispone di un bilanciatore del carico che invia richieste a più server web di cui è stato eseguito il deployment in più zone per garantire un'alta disponibilità. Le latenze potrebbero variare a seconda del server web che elabora una richiesta a causa delle differenze di latenza tra 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 uno dei tanti server web. I server web sono tutti collegati 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 al 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 in test è 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 utilizzare il sistema di database in modo sufficientemente intenso se le macchine client che generano il carico non dispongono di una CPU sufficiente.
Test di scalabilità
I test di scalabilità sono un altro aspetto dei test delle prestazioni. L'adattabilità si riferisce al modo in cui le metriche sul rendimento cambiano in base alla variazione di una caratteristica di un carico di lavoro. Ecco alcuni esempi di studi sulla scalabilità:
- In che modo un aumento del numero di richieste in parallelo influisce sul throughput e sui tempi di risposta?
- In che modo un aumento delle dimensioni del database influisce sulla velocità effettiva delle transazioni e sui tempi di risposta?
I test di scalabilità consistono in più esecuzioni di un carico di lavoro in cui una singola dimensione varia da un'esecuzione all'altra e vengono raccolte e tracciate una o più metriche. Questo tipo di test consente di prendere decisioni in merito ai colli di bottiglia esistenti nel sistema, alla quantità di carico che il sistema può gestire in base a 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 farlo utilizza le risorse della macchina su cui è in esecuzione AlloyDB Omni. Le dimensioni delle macchine molto piccole hanno risorse di memoria e CPU limitate, quindi per il benchmarking consigliamo di utilizzare dimensioni delle macchine di almeno quattro vCPU.