I benchmark sono una delle attività eseguite dagli amministratori di database. Li esegui per vedere come si comporta il tuo hardware, li esegui per vedere come l'applicazione e il database funzionano insieme sotto pressione. Li esegui in molte situazioni diverse. Parliamo un po' di loro, quali sono le sfide che dovrai affrontare, quali sono i problemi da evitare.
Tipi di benchmark
Ogni benchmark è diverso. Hanno scopi diversi e devono essere presi in considerazione quando si prevede di eseguirne uno. In generale, puoi definire due tipi principali di benchmark:benchmark sintetico e, chiamiamolo così, benchmark del "mondo reale".
I benchmark sintetici sono in genere strumenti che simulano una sorta di carico di lavoro. Può essere un carico di lavoro OLTP come nel caso di Sysbench, può essere un benchmark "standard" come in TPC-C o TPC-H. Di solito l'idea è che un tale benchmark simuli una sorta di carico di lavoro e potrebbe essere utile se il carico di lavoro del mondo reale seguirà lo stesso schema. Può anche essere utilizzato per determinare il modo in cui la combinazione di configurazione hardware e database funziona insieme in un determinato tipo di carico di lavoro. I vantaggi dei benchmark sintetici sono abbastanza chiari. Puoi eseguirli ovunque, non dipendono da una configurazione particolare o da una progettazione dello schema. Bene, lo fanno, ma escogitano strumenti per impostare tutto dal server di database vuoto. Lo svantaggio principale è che questo non è il tuo carico di lavoro. Se hai intenzione di eseguire test OLTP utilizzando Sysbench, devi tenere presente che la tua applicazione non sarà mai Sysbench. Può anche eseguire il carico di lavoro OLTP ma il mix di query sarà diverso. Mai, in nessun caso, il benchmark sintetico ti dirà esattamente come si comporterà la tua applicazione su un dato mix hardware/configurazione.
Dall'altra parte dello spettro abbiamo quello che abbiamo chiamato benchmark del "mondo reale". Ciò che intendiamo qui con questo è un benchmark che utilizza un set di dati e query relative alla tua applicazione. Non ha sempre un set di dati completo e un mix di query completo. Potresti voler concentrarti su alcune parti della tua applicazione, ma l'idea principale alla base è che vuoi comprendere le esatte interazioni tra l'applicazione, l'hardware e la configurazione del database, in generale o in alcuni aspetti particolari.
Come accennato in precedenza, abbiamo due tipi principali e diversi di benchmark, ma hanno comunque alcuni aspetti comuni che devi considerare durante il tentativo di eseguire i benchmark.
-
Decidi cosa vuoi testare
Prima di tutto, il benchmarking per il bene di eseguire benchmark non ha senso. Deve essere progettato per realizzare effettivamente qualcosa. Cosa vuoi ottenere dalla corsa del benchmark? Vuoi ottimizzare le query? Vuoi modificare la configurazione? Vuoi valutare la scalabilità del tuo stack? Vuoi preparare il tuo stack per un carico maggiore? Vuoi fare un tweeking di configurazione generico per un nuovo progetto? Vuoi determinare le migliori impostazioni per il tuo hardware? Questi sono esempi di obiettivi che potresti voler raggiungere. Ognuno di questi richiederà un approccio diverso e una diversa configurazione del benchmark.
-
Apporta una modifica alla volta
Qualunque cosa tu stia testando e modificando, è della massima importanza che apporti una sola modifica alla configurazione alla volta. Questo è davvero fondamentale. Il benchmark ha lo scopo di darti un'idea delle prestazioni. Query al secondo, latenza, 99 percentile, tutto questo ti dice quanto velocemente puoi eseguire le query e quanto è stabile e prevedibile il carico di lavoro. È facile capire se la modifica apportata alla configurazione, all'hardware o al mix di query cambia qualcosa:le metriche del benchmark avranno un aspetto diverso. Il fatto è che se apporti un paio di modifiche contemporaneamente, non c'è modo di dire quale sia responsabile del risultato complessivo. Può andare anche oltre. Supponiamo che tu abbia modificato due valori nella configurazione del database. Valore A e B. Il miglioramento complessivo è del 20%, il che è abbastanza buono solo per una modifica della configurazione. Sotto il cofano, tuttavia, la modifica al valore A ha portato un miglioramento del 30% mentre un'ulteriore modifica al valore B lo ha riportato al 20%. Con più modifiche contemporaneamente puoi solo osservare il loro impatto comune, questo non è il modo per determinare correttamente il risultato di ogni singola modifica apportata. Certo, questo aumenta notevolmente il tempo che dedichi all'esecuzione del benchmark, ma è così.
-
Esegui più esecuzioni di benchmark
I computer sono sistemi complessi di per sé. Hanno più componenti che interagiscono tra loro:memoria, CPU, disco, rete. Quindi aggiungiamo a questa virtualizzazione la containerizzazione. Quindi software:sistema operativo, applicazione, database. Strato su strato su strato su strato di elementi che interagiscono in qualche modo. Non è facile prevederne il comportamento. Bene, puoi dire che è quasi impossibile prevedere con precisione il comportamento di sistemi così complessi. Questo è il motivo per cui eseguire una corsa di benchmark non è sufficiente per trarre le conclusioni. E se, a tua insaputa, qualche elemento, totalmente estraneo a ciò che vuoi testare, influisca sulle prestazioni complessive? Carico elevato su un'altra macchina virtuale situata sullo stesso host. Un altro server sta trasmettendo in streaming il backup sulla rete. Ciò potrebbe influire temporaneamente sulle prestazioni e distorcere i risultati del benchmark. Se esegui una sola corsa di benchmark, ti ritroverai con risultati errati. Questo è il motivo per cui la migliore pratica è eseguire più passaggi di un benchmark e quindi rimuovere il più lento e il più veloce, facendo la media degli altri.
-
Un'immagine vale migliaia di parole
Beh, questa è praticamente una descrizione molto accurata del benchmarking. Se possibile, genera sempre dei grafici. Idealmente, tieni traccia delle metriche durante il benchmark il più spesso possibile. Un secondo granularità dovrebbe essere sufficiente per la maggior parte dei casi. Per evitare di scrivere migliaia di parole, includeremo questo esempio. Cosa pensi sia più utile? Questo insieme di output di benchmark che rappresentano il QPS medio per ciascuno dei 10 passaggi, ogni passaggio richiede 600 secondi
11650.52
11237.97
11550.16
11247.08
11177.78
11163.76
11131.47
11235.06
11235.59
11277.25
O questa trama:
Il QPS medio è 11k ma la realtà è che le prestazioni sono ovunque posto, inclusi i cali a 0 query eseguite in un secondo, ed è sicuramente qualcosa che vuoi lavorare e migliorare sui sistemi di produzione.
-
Le query al secondo non sono la metrica più importante
Puoi pensare che la query al secondo sia il Santo Graal delle prestazioni in quanto rappresenta il numero di query che un database può eseguire in un secondo. La verità è che non è la metrica più importante, soprattutto se parliamo di output medio da un benchmark. QPS rappresenta il throughput ma ignora la latenza. Puoi provare a inviare un grande volume di query, ma poi finisci per aspettare che restituiscano risultati. Questo non è ciò che gli utenti si aspettano dall'applicazione. Gli utenti si aspettano prestazioni stabili. Non deve essere velocissimo, ma quando un'azione richiede un secondo per essere completata, tendiamo ad aspettarci che l'esecuzione di quell'azione richieda sempre 1 secondo. Se, per qualche motivo, inizia a richiedere più tempo, gli esseri umani tendono a diventare ansiosi. Questo è il motivo principale per cui tendiamo a preferire la latenza, in particolare il suo P99 (99° percentile) come metrica più affidabile. La latenza ci dice per quanto tempo l'applicazione ha dovuto attendere il risultato dal database. P99 ci dice latenza che il 99% delle query ha un valore inferiore a. Supponiamo di avere un P99 di 100 ms, significa che il 99% delle query restituisce risultati non inferiori a 100 ms. Se vediamo una latenza di P99 bassa, significa che quasi tutte le query vengono restituite rapidamente e funzionano in modo stabile e prevedibile. Questo è qualcosa che i nostri utenti vogliono vedere.
-
Capire cosa sta succedendo prima di trarre conclusioni
Ultimo punto che abbiamo in questo breve blog ma diremmo che è il più importante. Vedrai diversi risultati e comportamenti strani e imprevisti durante i benchmark. Peggio ancora, potresti vedere risultati piuttosto standard, ripetitivi ma comunque imperfetti. La maggior parte di essi può essere tracciata in base al comportamento del database o dell'hardware. Questo è davvero cruciale:prima di dare per scontato il risultato, dovresti essere in grado di spiegare il comportamento e descrivere cosa è successo. Sappiamo che non è facile e sappiamo che richiede davvero una conoscenza specifica del database, in particolare la conoscenza relativa agli interni del database. Sappiamo che nel mondo reale le persone in genere non si preoccupano di questo, vogliono solo ottenere dei risultati. Il fatto è che, soprattutto per i casi in cui stai tentando di migliorare le prestazioni attraverso modifiche alla configurazione o all'hardware, capire cosa è successo sotto il cofano ti consente di scegliere il modo corretto in cui dovrebbe procedere la tua messa a punto. Permette anche di capire se il benchmark che è stato eseguito può avere un senso. Stiamo effettivamente testando l'elemento corretto? Un esempio potrebbe essere un test eseguito sulla rete (perché non si desidera utilizzare i core della CPU locale del nodo del database per lo strumento di benchmark). È molto probabile che la rete stessa e il carico della CPU di softirq saranno il fattore limitante, molto prima di quanto si colpirebbero colli di bottiglia "previsti" come la saturazione della CPU. Se non sei a conoscenza del tuo ambiente e del suo comportamento, misurerai le prestazioni della tua rete per trasferire grandi volumi di dati, non le prestazioni della CPU.
Come puoi vedere, il benchmarking non è la cosa più semplice da fare, devi avere un livello di consapevolezza di quello che sta succedendo, dovresti avere un piano adeguato per quello che stai per fare e cosa vuoi provare? Nella prossima parte di questo blog analizzeremo alcuni dei casi di test del mondo reale. Cosa può andare storto, quali problemi incontreremo e come affrontarli.
