Che consiglio mi puoi dare per scrivere un benchmark significativo?

Question

Ho sviluppato un framework che viene utilizzato da diversi team nella nostra organizzazione. Quei "moduli", sviluppati in cima a questo framework, possono comportarsi in modo abbastanza diverso ma sono tutti piuttosto risorse che consumano anche se alcuni sono più di altri. Tutti ricevono i dati in input, li analizzano e / o li trasformano e li inviano ulteriormente.

Abbiamo pianificato di acquistare nuovo hardware e il mio capo mi ha chiesto di definire e implementare un benchmark basato sui moduli per confrontare le diverse offerte che abbiamo.

La mia idea è quella di avviare semplicemente in sequenza ogni modulo con un gruppo di dati ben scelto come input.

Hai qualche consiglio? Qualche commento su questa semplice procedura?

Answer 1

La tua domanda è piuttosto ampia, quindi purtroppo anche la mia risposta non sarà molto specifica.

In primo luogo, il benchmarking è difficile. Non sottovalutare lo sforzo necessario per produrre risultati significativi, ripetibili e di elevata fiducia.

Secondo, qual è il tuo obiettivo prestazionale? È throughput (transazione o operazioni al secondo)? È latenza (tempo necessario per eseguire una transazione)? Ti interessa la performance media? Mi preoccupo delle prestazioni peggiori? Ti interessa il caso peggiore in assoluto o mi interessa che il 90%, il 95% o qualche altro percentile ottengano prestazioni adeguate?

A seconda dell'obiettivo che hai, allora dovresti progettare il tuo benchmark per misurarlo con quell'obiettivo. Pertanto, se sei interessato alla velocità effettiva, probabilmente desideri inviare messaggi / transazioni / input nel tuo sistema a una velocità prestabilita e vedere se il sistema sta mantenendo il passo.

Se sei interessato alla latenza, invierai messaggi / transazioni / input e misurerai quanto tempo impiega per elaborarli.

Se sei interessato alle prestazioni nel caso peggiore, aggiungerai carico al sistema fino a qualsiasi cosa tu consideri "realistica". (o qualunque cosa la progettazione del sistema sostenga che dovrebbe supportare.)

In secondo luogo, non si dice se questi moduli saranno associati alla CPU, agli I / O, se potranno sfruttare più CPU / core, ecc. Mentre si sta provando a valutare diverse soluzioni hardware, è possibile che la tua applicazione beneficia maggiormente di un ottimo sottosistema I / O rispetto a un numero enorme di CPU.

In terzo luogo, il miglior benchmark (e il più difficile) è quello di caricare in modo realistico il sistema. Ciò significa che si registrano dati da un ambiente di produzione e si inserisce la nuova soluzione hardware attraverso questi dati. Fare questo è più difficile di quanto sembri, spesso significa aggiungere tutti i tipi di punti di misura nel sistema per vedere come si comporta (se non li hai già), modificare il sistema esistente per aggiungere capacità di registrazione / riproduzione, modificando il riproduzione da eseguire a velocità diverse e ottenere un ambiente realistico (cioè simile alla produzione) per i test.

Answer 2

Il benchmark più significativo è misurare le prestazioni del tuo codice nell'uso quotidiano. Questo ovviamente ti fornirà i numeri più realistici.

Scegli diversi set di dati di vita reale e sottoponili agli stessi processi che la tua organizzazione utilizza ogni giorno. Per ulteriore credito, parla con le persone che usano il tuo framework e chiedi loro di fornire alcuni "migliori casi", "normali" e "peggiori" dati. Anonimizzare i dati in caso di problemi di privacy, ma cercare di non modificare nulla che possa influire sulle prestazioni.

Ricorda che stai confrontando e confrontando due set di hardware, non il tuo framework. Tratta tutto il software come una scatola nera e misura semplicemente le prestazioni dell'hardware.

Infine, considera di salvare i set di dati e utilizzarli per valutare in modo analogo eventuali modifiche successive apportate al software.

Answer 3

Se il tuo sistema dovrebbe essere in grado di gestire più client contemporaneamente, allora il tuo benchmark dovrebbe riflettere questo. Nota che alcune chiamate non funzioneranno bene insieme. Ad esempio, avere 25 thread che pubblicano lo stesso bit di informazioni allo stesso tempo potrebbe portare a blocchi all'estremità del server, distorcendo così i risultati.

Da un punto di vista pratico, ho usato Perl e il suo Modulo benchmark per raccogliere le informazioni a cui tengo.

Answer 4

Se stai confrontando hardware diverso, quindi misurare il costo per transazione ti darà un buon confronto dei compromessi dell'hardware per le prestazioni. Una configurazione può darti le migliori prestazioni, ma costa troppo. Una configurazione meno costosa può offrire prestazioni adeguate.

È importante emulare il "caso peggiore" o "ora di punta" di carico. È anche importante testare con "tipico" volumi. È un atto di bilanciamento per ottenere un buon utilizzo del server, che non costa troppo, che offre le prestazioni richieste.

I test su configurazioni hardware diventano rapidamente costosi. Un'altra opzione praticabile è prima misurare la configurazione che hai, quindi simulare quel comportamento su sistemi virtuali usando un modello.

Answer 5

Se puoi, prova a registrare alcune operazioni che gli utenti (o i processi) stanno facendo con il tuo framework, idealmente usando un clone del sistema reale. Questo ti dà i dati più realistici. Cose da considerare:

1. Quali funzioni vengono utilizzate più spesso?
2. Quanti dati vengono trasferiti?
3. Non assumere nulla. Se pensi che "sarà veloce / lento", non scommettere su di esso. In 9 casi su 10, ti sbagli.

Crea una top ten per 1 + 2 e lavora da quella.

Detto questo: se sostituisci il vecchio hardware con nuovo hardware, puoi aspettarti un'esecuzione di circa il 10% più veloce per ogni anno che è trascorso da quando hai acquistato il primo set (se i sistemi sono abbastanza uguali).

Se si dispone di un sistema specializzato, i numeri potrebbero essere completamente diversi ma, di solito, il nuovo hardware non cambia molto. Ad esempio, l'aggiunta di un indice utile a un database può ridurre il tempo di esecuzione di una query da due ore a due secondi. L'hardware non ti darà mai questo.

Answer 6

A mio avviso, esistono due tipi di benchmark quando si tratta di software di benchmarking. Innanzitutto, i microbenchmark, quando si tenta di valutare un pezzo di codice in isolamento o come un sistema gestisce il carico di lavoro strettamente definito. Confronta due algoritmi di ordinamento scritti in Java. Confronta due browser Web con la velocità con cui ciascuno può eseguire alcune operazioni di manipolazione DOM. In secondo luogo, ci sono benchmark di sistema (ho appena creato il nome), quando si tenta di valutare un sistema software con un carico di lavoro realistico. Confronta il mio backend basato su Python in esecuzione su Google Compute Engine e su Amazon AWS.

Quando si ha a che fare con Java e simili, tenere presente che la VM deve riscaldarsi prima di poter offrire prestazioni realistiche. Se si misura il tempo con il comando time , verrà incluso il tempo di avvio di JVM. Devi quasi sempre ignorare l'ora di avvio o tenerne traccia separatamente.

Microbenchmarking

Durante la prima esecuzione, le cache della CPU vengono riempite con i dati necessari. Lo stesso vale per le cache del disco. Durante alcune esecuzioni successive la VM continua a riscaldarsi, il che significa che JIT compila ciò che ritiene utile da compilare. Vuoi ignorare queste corse e iniziare a misurare in seguito.

Effettua molte misurazioni e calcola alcune statistiche. Media, mediana, deviazione standard, traccia un grafico. Guardalo e vedi quanto cambia. Le cose che possono influenzare il risultato includono pause GC nella VM, ridimensionamento di frequenza sulla CPU, alcuni altri processi possono avviare alcune attività in background (come la scansione antivirus), il sistema operativo può decidere di spostare il processo su un altro core della CPU, se si hanno l'architettura NUMA , i risultati sarebbero ancora più marcati.

Nel caso di microbenchmark, tutto questo è un problema. Uccidi quali processi puoi prima di iniziare. Usa una libreria di benchmarking che può fare qualcosa per te. Come https://github.com/google/caliper e simili.

Analisi comparativa del sistema

In caso di benchmarking di un sistema con un carico di lavoro realistico, questi dettagli non ti interessano davvero e il tuo problema è "solo". per sapere cos'è un carico di lavoro realistico, come generarlo e quali dati raccogliere. È sempre meglio se è possibile strumentare un sistema di produzione e raccogliere dati lì. Di solito è possibile farlo, poiché si stanno misurando le caratteristiche dell'utente finale (per quanto tempo ha eseguito il rendering di una pagina Web) e questi sono associati a I / O in modo che la raccolta di dati non rallenti il ??sistema. (La pagina deve essere spedita all'utente tramite la rete, non importa se registriamo anche alcuni numeri nel processo).

Prestare attenzione alla differenza tra profilazione e benchmarking. Il benchmarking può darti il ??tempo assoluto speso a fare qualcosa, la profilazione ti dà il tempo relativo speso a fare qualcosa rispetto a tutto ciò che era necessario fare. Questo perché i profiler eseguono programmi fortemente strumentati (la tecnica comune è di fermare il mondo ogni poche centinaia di ms e salvare una traccia dello stack) e la strumentazione rallenta notevolmente tutto.