Procedure consigliate per il benchmarking delle prestazioni di Database di Azure per MySQL - Server flessibile

2024-11-27

Le prestazioni sono una caratteristica distintiva di qualsiasi applicazione ed è fondamentale definire una strategia chiara per l'analisi e la valutazione delle prestazioni di un database quando si gestiscono requisiti di carichi di lavoro variabili di un'applicazione.

Questo articolo fornisce considerazioni e procedure consigliate per l'esecuzione di benchmark delle prestazioni nel server flessibile di Database di Azure per MySQL.

Test delle prestazioni

Il benchmarking delle prestazioni dei sistemi di database relazionali inizialmente potrebbe sembrare un'attività semplice. Dopo tutto, è relativamente facile valutare manualmente le prestazioni delle singole query e persino avviare semplici test sintetici usando uno degli strumenti di benchmarking disponibili. Questi tipi di test richiedono poco tempo e producono rapidamente risultati facili da comprendere.

Tuttavia, il benchmarking delle prestazioni dei sistemi di produzione reali richiede molto impegno aggiuntivo. Non è facile progettare, implementare ed eseguire test che sono realmente rappresentativi dei carichi di lavoro di produzione. È ancora più difficile prendere decisioni sugli stack di dati di produzione in base ai risultati di una serie di benchmark eseguiti in un ambiente isolato.

Metodologie di test delle prestazioni

Benchmark sintetici

I test sintetici sono progettati per mettere stress in un sistema di database usando campioni di carico di lavoro artificiali che simulano risultati ripetibili in un ambiente di database. Ciò consente ai clienti di eseguire confronti tra più ambienti per misurare la risorsa di database corretta per le distribuzioni di produzione.

Esistono diversi vantaggi associati all'uso di benchmark sintetici. Ad esempio:

Sono prevedibili, ripetibili e consentono test selettivi, ad esempio test di sola scrittura, test di sola lettura, una combinazione di test di scrittura e lettura e test mirati su una tabella.
Fornire risultati complessivi che possono essere rappresentati usando metriche semplici, ad esempio "query al secondo", "transazioni al secondo" e così via.
Non richiedere conoscenze specifiche dell'applicazione o dell'ambiente per la compilazione e l'esecuzione.
Possibilità di esecuzione rapida e con poca o nessuna preparazione. Tuttavia, esistono anche degli svantaggi associati, in quanto:
Gli esempi di carichi di lavoro artificiali non sono rappresentativi del traffico delle applicazioni reali.
I risultati non possono essere usati per prevedere accuratamente le prestazioni dei carichi di lavoro in produzione.
Potrebbero non esporre caratteristiche di prestazioni specifiche del prodotto quando vengono usate per testare prodotti di database diversi.
È facile eseguire i test in modo errato e produrre risultati ancora meno rappresentativi.

I test sintetici sono utili per confronti rapidi tra prodotti. È anche possibile usarli per implementare meccanismi di monitoraggio continuo delle prestazioni. Ad esempio, è possibile eseguire un gruppo di test ogni fine settimana per convalidare le prestazioni di base del sistema di database, rilevare anomalie e prevedere modelli di prestazioni a lungo termine, ad esempio riduzione delle prestazioni della latenza delle query a causa della crescita dei dati.

Benchmark reali

Con i test reali, il database viene presentato con esempi di carico di lavoro simili al traffico di produzione. È possibile ottenere questo risultato direttamente riproducendo un log di query di produzione e misurando le prestazioni del database. È anche possibile ottenere questo risultato indirettamente eseguendo il test a livello di applicazione e misurando le prestazioni dell'applicazione in un determinato server di database.

Esistono diversi vantaggi associati all'uso di benchmark reali, in quanto:

Offrono una visualizzazione accurata delle prestazioni del sistema in condizioni di produzione reali.
A differenza dei test sintetici semplificati, potrebbero rivelare caratteristiche specifiche dell'applicazione o del database.
Forniscono assistenza per la pianificazione della capacità correlata alla crescita delle applicazioni.

Esistono anche alcuni svantaggi: benchmark reali:

Sono difficili da progettare ed eseguire.
Devono essere mantenuti per garantire la pertinenza man mano che l'applicazione si evolve.
Forniscono risultati significativi solo nel contesto di una determinata applicazione.

Quando si prepara una modifica importante all'ambiente, ad esempio quando si distribuisce un nuovo prodotto di database, è consigliabile usare test reali. In una situazione di questo tipo, un benchmark completo eseguito usando un carico di lavoro di produzione effettivo è di notevole aiuto. Non solo fornirà risultati accurati che è possibile considerare attendibili, ma rimuoverà o almeno ridurrà notevolmente il numero di "sconosciuti" sul sistema.

Scegliere la metodologia di test "corretta"

La metodologia di test "corretta" per i propri scopi dipende interamente dall'obiettivo dei test.

Se si vuole confrontare rapidamente prodotti di database diversi usando esempi di dati e carichi di lavoro artificiali, è possibile usare in modo sicuro un programma di benchmark esistente che genera i dati ed esegue automaticamente il test.

Per valutare con precisione le prestazioni di un'applicazione reale che si intende eseguire in un nuovo prodotto di database, è necessario eseguire test di benchmark reali. Ogni applicazione ha un insieme univoco di requisiti e caratteristiche di prestazioni ed è consigliabile includere test di benchmark reali in tutte le valutazioni delle prestazioni.

Per indicazioni sulla preparazione e l'esecuzione di benchmark sintetici e reali, vedere le sezioni seguenti più avanti in questo post:

Preparazione ed esecuzione di test sintetici
Preparazione ed esecuzione di test reali

Procedure consigliate per i test delle prestazioni

Raccomandazioni specifiche del server

Ridimensionamento del server

Quando si avviano istanze del server flessibile di Database di Azure per MySQL per eseguire il benchmarking, usare un livello di istanza del server flessibile di Database di Azure per MySQL, uno SKU e un numero di istanze corrispondente all'ambiente di database corrente.

Ad esempio:

Se il server corrente ha otto core CPU e 64 GB di memoria, la scelta ottimale è un'istanza in base allo SKU Standard_E8ds_v4.
Se l'ambiente di database corrente usa repliche in lettura, usare le repliche in lettura di Database di Azure per MySQL - Server flessibile.

A seconda dei risultati dei test di benchmark, è possibile decidere di usare dimensioni e conteggi di istanze diversi in produzione. Tuttavia, è comunque consigliabile assicurarsi che le specifiche iniziali delle istanze di test siano vicine alle specifiche del server correnti per fornire un confronto più accurato tra "mele e mele".

Configurazione del server

Se l'applicazione/benchmark richiede che alcune funzionalità del database siano abilitate, prima di eseguire il test di benchmark modificare adeguatamente i parametri del server. Ad esempio, potrebbe essere necessario:

Impostare un fuso orario del server non predefinito.
Impostare un parametro "max_connections" personalizzato se il valore predefinito non è sufficiente.
Configurate il pool di thread se l'istanza di Database di Azure per MySQL Server Flessibile esegue la versione 8.0.
Abilitare log di query lenti se si prevede di usarli nell'ambiente di produzione, in modo da poter analizzare eventuali query con colli di bottiglia.

Altri parametri, ad esempio quelli correlati alle dimensioni di vari buffer e cache del database, sono già preconfigurati nel server flessibile di Database di Azure per MySQL ed è possibile lasciarli inizialmente impostati sui valori predefiniti. Anche se è possibile modificarli, è consigliabile evitare di apportare modifiche ai parametri del server, a meno che i benchmark delle prestazioni non mostrino che una determinata modifica migliori effettivamente le prestazioni.

Quando si eseguono test confrontando il server flessibile di Database di Azure per MySQL con altri prodotti di database, assicurarsi di abilitare tutte le funzionalità che si prevede di usare nell'ambiente di produzione nei database di test. Ad esempio, se non si abilita la disponibilità elevata (HA) con ridondanza della zona e le repliche in lettura nell'ambiente di test, i risultati potrebbero non riflettere accuratamente le prestazioni reali.

Consigli specifici del client

Tutti i benchmark delle prestazioni implicano l'uso di un client, quindi, indipendentemente dalla metodologia di benchmarking scelta, assicurarsi di considerare i consigli seguenti lato client.

Assicurati che le istanze client esistano nella stessa rete virtuale di Azure (VNet) dell'istanza del server flessibile Azure Database per MySQL che stai testando. Per le applicazioni sensibili alla latenza, è consigliabile inserire istanze client nella stessa zona di disponibilità (AZ) del server di database.
Se si prevede che un'applicazione di produzione venga eseguita su più istanze (ad esempio una flotta di server app dietro un servizio di bilanciamento del carico), è consigliabile usare più istanze client quando si esegue il benchmark.
Assicurarsi che tutte le istanze client abbiano una capacità di calcolo, memoria, I/O e rete adeguati per gestire il benchmark. In altre parole, i client devono essere in grado di produrre richieste più velocemente di quanto il motore di database possa gestirle. Tutti i sistemi operativi forniscono strumenti di diagnostica (ad esempio "top", "htop", "dstat" o "iostat" in Linux) che consentono di diagnosticare l'utilizzo delle risorse nelle istanze client. È consigliabile usare questi strumenti e assicurarsi che tutte le istanze client abbiano sempre CPU, memoria, rete e capacità di I/O di riserva mentre il benchmark è in esecuzione.

Anche con uno SKU di grandi dimensioni, una singola istanza client potrebbe non essere sempre in grado di generare richieste abbastanza rapidamente da saturare il database. A seconda della configurazione di test, il server flessibile di Database di Azure per MySQL può essere in grado di gestire centinaia di migliaia di richieste di lettura/scrittura al secondo, che possono essere più di un singolo client. Per evitare conflitti lato client durante test delle prestazioni pesanti, è quindi una pratica comune eseguire un benchmark da più istanze client in parallelo.

Importante

Se si esegue il benchmarking dell'applicazione usando uno script generatore di traffico o uno strumento di terzi (ad esempio Apache Benchmark, Apache JMeter o Siege), è consigliabile valutare anche l'istanza in cui viene eseguito lo strumento usando i consigli evidenziati in precedenza.

Preparare ed eseguire test sintetici

Gli strumenti di benchmarking sintetico, ad esempio sysbench, sono facili da installare ed eseguire, ma in genere richiedono un determinato grado di configurazione e ottimizzazione prima che qualsiasi benchmark specifico possa ottenere risultati ottimali.

Conteggio e dimensioni delle tabelle

Il numero e le dimensioni delle tabelle generate prima del benchmarking devono essere grandi. Ad esempio, è improbabile che i test eseguiti in una singola tabella con 100.000 righe generino risultati utili, perché è probabile che tale set di dati sia più piccolo di qualsiasi database reale. Per un confronto, un benchmark che usa più tabelle (ad esempio 10-25) con 5 milioni di righe ognuna potrebbe essere una rappresentazione più realistica del carico di lavoro in tempo reale.

Modalità test

Con la maggior parte degli strumenti di benchmark (incluso il sysbench più diffuso), è possibile definire il tipo di carico di lavoro che si vuole eseguire sul server. Ad esempio, lo strumento può generare:

Query di sola lettura con sintassi identica ma parametri diversi.
Query di sola lettura di tipi diversi (selezione punto, selezione intervallo, selezione con ordinamenti e così via).
Istruzioni di sola scrittura che modificano singole righe o intervalli di righe.
Una combinazione di istruzioni di lettura/scrittura.

È possibile usare carichi di lavoro di sola lettura o di sola scrittura se si vogliono testare le prestazioni e la scalabilità del database in questi scenari specifici. Tuttavia, un benchmark rappresentativo deve in genere includere una buona combinazione di istruzioni di lettura/scrittura, perché questo è il tipo di carico di lavoro che la maggior parte dei database OLTP deve gestire.

Livello di concorrenza

Il livello di concorrenza è il numero di thread che eseguono contemporaneamente operazioni sul database. La maggior parte degli strumenti di benchmark usa un singolo thread per impostazione predefinita, che non è rappresentativo di ambienti di database reali, poiché i database vengono usati raramente da un singolo client alla volta.

Per testare le prestazioni di picco teorico di un database, usare il processo seguente:

Eseguire più test usando un numero di thread diverso per ogni test. Ad esempio, iniziare con 32 thread e quindi aumentare il numero di thread per ogni test successivo (64, 128, 256 e così via).
Continuare ad aumentare il numero di thread fino a quando le prestazioni del database non si stabilizzano. Si tratta del picco delle prestazioni teoriche.
Quando si determina che le prestazioni del database si arrestano a un determinato livello di concorrenza, è comunque possibile tentare di aumentare il numero di thread un paio di volte, che mostrerà se le prestazioni rimangono stabili o iniziano a peggiorare. Per altre informazioni, vedere il post di blog Benchmarking di Database di Azure per MySQL - Server flessibile – usando Sysbench.

Preparare ed eseguire test reali

Ogni applicazione è unica in termini di caratteristiche dei dati e requisiti di prestazioni. Di conseguenza, è difficile trovare un unico elenco universale di passaggi che sarebbe sufficiente per preparare ed eseguire un benchmark rappresentativo del mondo reale in un ambiente di database arbitrario.

Le idee presentate in questa sezione sono destinate a semplificare i progetti di test delle prestazioni.

Preparare i dati di test

Prima di eseguire benchmark delle prestazioni sul server flessibile di Database di Azure per MySQL, assicurarsi che il server sia popolato con un campione rappresentativo del set di dati di produzione.

Quando possibile, usare una copia completa del set di produzione. Quando ciò non è possibile, usare i suggerimenti seguenti per determinare quali parti di dati è consigliabile includere sempre e quali dati è possibile escludere.

Il server di test deve includere tutti gli oggetti, ovvero schemi, tabelle, funzioni e procedure, usati direttamente dal benchmark. Ogni tabella deve essere popolata completamente, ovvero deve contenere tutte le righe contenute in produzione. Se le tabelle non sono completamente popolate, ad esempio contengono solo un piccolo campione del set di righe, i risultati del benchmark non saranno rappresentativi.
Escludere le tabelle usate dalle applicazioni di produzione ma che non fanno parte del traffico operativo continuo. Ad esempio, se un database contiene un set di dati operativi live e dati storici usati per l'analisi, i dati storici potrebbero non essere necessari per eseguire benchmark.
Popolare tutte le tabelle copiate nel server di test con dati di produzione reali anziché esempi artificiali generati a livello di codice.

Progettare benchmark dell'applicazione

Il processo di alto livello per l'esecuzione di benchmark dell'applicazione è il seguente:

Crea un'istanza di server flessibile del Database di Azure per MySQL e riempi con una copia dei tuoi dati di produzione.
Distribuire una copia dell'applicazione in Azure.
Configurare l'applicazione per utilizzare l'istanza di Azure Database per MySQL Flexible Server.
Eseguire test di carico sull'applicazione e valutare i risultati.

Questo approccio è particolarmente utile quando è possibile distribuire facilmente una copia dell'applicazione in Azure. Consente di eseguire una valutazione delle prestazioni nel modo più completo e accurato, ma esistono ancora alcune raccomandazioni da tenere presenti.

Lo strumento usato per generare il traffico dell'applicazione deve essere in grado di generare una combinazione di richieste rappresentative del carico di lavoro di produzione. Ad esempio, non testare ripetutamente l'accesso allo stesso URL dell'applicazione, perché questo probabilmente non è rappresentativo del modo in cui i client usano l'applicazione nel mondo reale.
Il pool di istanze del client e dell'applicazione deve essere abbastanza potente da generare richieste, gestirle e ricevere risposte dal database senza introdurre colli di bottiglia.
Il livello di concorrenza (il numero di richieste parallele generate dallo strumento di benchmark) deve corrispondere o superare leggermente il livello di concorrenza previsto osservato nell'applicazione.

Progettare benchmark di database

Se non è possibile distribuire facilmente una copia dell'applicazione in Azure, è necessario eseguire il benchmark eseguendo istruzioni SQL direttamente sul database. A tale scopo, utilizzare la procedura di alto livello seguente:

Identificare le istruzioni SQL più comunemente visualizzate nel carico di lavoro di produzione.
In base alle informazioni raccolte nel primo passaggio, preparare un ampio campione di istruzioni SQL da testare.
Creare un nodo del server flessibile di Database di Azure per MySQL e popolarlo con una copia dei dati di produzione.
Avviare le istanze client della macchina virtuale di Azure in Azure.
Dalle macchine virtuali eseguire l'esempio di carico di lavoro SQL sull'istanza del server flessibile di Database di Azure per MySQL e valutare i risultati.

Esistono due approcci principali per generare il payload di test (esempi di istruzioni SQL):

Osservare/registrare il traffico SQL che si verifica nel database corrente, quindi generare esempi SQL in base a tali osservazioni. Per informazioni dettagliate su come registrare il traffico di query sfruttando una combinazione di log di controllo e registrazione lenta delle query in Database di Azure per MySQL - Server flessibile.
Usare i log di query effettivi come payload. Strumenti di terzi, ad esempio "Percona Playback", possono generare carichi di lavoro multithread in base ai log di query lenti di MySQL.

Se si decide di generare manualmente l'esempio SQL, assicurarsi che l'esempio contenga:

Numero sufficiente di istruzioni univoche.

Esempio: se si determina che il carico di lavoro di produzione usa 15 tipi principali di istruzioni, non è sufficiente che l'esempio contenga un totale di 15 istruzioni (una per tipo). Per un esempio così piccolo, il database memorizza facilmente nella cache i dati necessari in memoria, rendendo il benchmark non rappresentativo. Fornire invece un esempio di query di grandi dimensioni per ogni tipo di istruzione e usare i consigli aggiuntivi seguenti.
Istruzioni di tipo diverso nelle corrette proporzioni.

Esempio: se si determina che il carico di lavoro di produzione usa 12 tipi di istruzioni, è probabile che alcuni tipi di istruzioni appaiano più spesso di altri. L'esempio deve riflettere queste proporzioni: se la query A appare 10 volte più spesso rispetto alla query B nel carico di lavoro di produzione, appare 10 volte più spesso anche nell'esempio.
Parametri di query che sono realisticamente casuali.

Se sono stati seguiti i consigli precedenti e l'esempio di query contiene gruppi di query dello stesso tipo/sintassi, i parametri di tali query devono essere casuali. Se l'esempio contiene un milione di query dello stesso tipo e sono tutte identiche (inclusi i parametri nelle condizioni WHERE), i dati necessari verranno facilmente memorizzati nella cache nella memoria del database, rendendo il benchmark non rappresentativo.
Ordine di esecuzione dell'istruzione che è realisticamente casuale.

Se si seguono i consigli precedenti e il payload di test contiene molte query di tipo diverso, è consigliabile eseguire queste query in un ordine realistico. Ad esempio, l'esempio potrebbe contenere 10 milioni di istruzioni SELECT e 1 milione di istruzioni UPDATE. In questo caso, l'esecuzione di tutte le operazioni SELECT prima di tutti le istruzioni UPDATE potrebbe non essere la scelta migliore, perché è probabile che non sia così che l'applicazione esegue query nel mondo reale. È più probabile che l'applicazione interfogli SELECT e UPDATE e che il test cerchi di simularlo.

Quando l'esempio di query è pronto, eseguirlo sul server usando un client MySQL della riga di comando o uno strumento come mysqlslapv.

Eseguire i test

Indipendentemente dal fatto che si esegua un benchmark sintetico o un test delle prestazioni dell'applicazione nel mondo reale, esistono diverse regole da seguire per assicurarsi di ottenere risultati più rappresentativi.

Eseguire test su più tipi di istanza

Si supponga di decidere di eseguire benchmark su un server db.r3.2xlarge e di verificare che le prestazioni dell'applicazione/query soddisfino già i requisiti. È anche consigliabile eseguire test su tipi di istanza più piccoli e di dimensioni maggiori, che offrono due vantaggi:

I test con tipi di istanza più piccoli potrebbero comunque produrre risultati ottimali in termini di prestazioni e rivelare potenziali opportunità di risparmio dei costi.
I test con tipi di istanze più grandi possono fornire idee o informazioni dettagliate sulle opzioni di scalabilità future.

Misurare sia le prestazioni sostenute che le prestazioni di picco

La strategia di test scelta deve fornire risposte a se il database fornirà un livello adeguato:

Prestazioni sostenute: si eseguirà come previsto nel normale carico di lavoro, quando il traffico degli utenti è uniforme e ben entro i livelli previsti?
Prestazioni di picco: sarà garantita la velocità di risposta dell'applicazione durante i picchi di traffico?

Considerare le linee guida seguenti:

Assicurarsi che le esecuzioni dei test siano sufficienti per valutare le prestazioni del database in uno stato stabile. Ad esempio, un test complesso che dura solo 10 minuti produrrà probabilmente risultati imprecisi, perché le cache e i buffer del database potrebbero non essere in grado di scaldarsi in un periodo di tempo così breve.
I benchmark possono essere molto più significativi e informativi se i livelli del carico di lavoro variano in tutto il test. Ad esempio, se l'applicazione riceve in genere il traffico da 64 client simultanei, avviare il benchmark con 64 client. Quindi, mentre il test è ancora in esecuzione, aggiungere 64 client aggiuntivi per determinare il comportamento del server durante un picco di traffico simulato.

Includere test di blackout/brownout nella procedura di benchmark

Le prestazioni del server sostenute sono una metrica importante e probabilmente diventano il punto principale di attenzione durante i test. Per le applicazioni mission-critical, tuttavia, i test delle prestazioni non devono smettere di misurare il comportamento del server in stato stabile.

Prendere in considerazione l'inclusione degli scenari seguenti nei test.

Test "Blackout", progettati per determinare il comportamento del database durante un riavvio o un arresto anomalo. Il server flessibile di Azure Database per MySQL introduce miglioramenti significativi nei tempi di ripristino in caso di arresto anomalo, e i test di riavvio e arresto anomalo sono fondamentali per comprendere come il server flessibile di Azure Database per MySQL contribuisca a ridurre i tempi di inattività dell'applicazione in tali scenari.
Test "Brownout", progettati per misurare la velocità con cui un database raggiunge i livelli di prestazioni nominali dopo un riavvio o un arresto anomalo. I database spesso richiedono tempo per ottenere prestazioni ottimali e il server flessibile di Database di Azure per MySQL introduce miglioramenti anche in questa area.

In caso di problemi di stabilità che interessano il database, tutte le informazioni raccolte durante i benchmark delle prestazioni consentono di identificare i colli di bottiglia o di ottimizzare ulteriormente l'applicazione per soddisfare le esigenze del carico di lavoro.

Condividi tramite