Monitora i numeri delle prestazioni

1

Ho un (grande) progetto software in un repository git. C'è una suite di benchmark che sputa un sacco di numeri (tempo per benchmark, allocazioni fatte per benchmark) che mi piacerebbe tracciare.

Qual è il modo migliore per controllare le modifiche alle prestazioni previste e non intenzionali in una tale configurazione?

(Idealmente, penso, c'è un pezzo di software libero che prende un repository git, uno script per ottenere i numeri, pianifica i lavori per il nuovo commit, controlla anche i vecchi commit quando è inattivo e presenta un'interfaccia web liscia con un sacco di grafici e strumenti di analisi.)

    
posta Joachim Breitner 07.07.2014 - 22:14
fonte

4 risposte

2

Ho una quantità limitata di esperienza con Jenkins . Una cosa che mi è veramente piaciuta è stata la visualizzazione del cruscotto che era stata creata dai miei colleghi, usando plugin per Jira, Subversion e Clover (copertura del codice). Jenkins supporta un buon numero di plugin e puoi svilupparli da solo.

So che Hudson ha un'estensibilità simile.

    
risposta data 07.07.2014 - 22:24
fonte
2

Credo che l'approccio migliore per il tuo caso sia l'utilizzo di Jenkins con il Plugin prestazioni . Ha grafici piacevoli e può essere utilizzato sia con JMeter sia con SoapUI .

Anche le prestazioni del test sono importanti. Secondo Martin Fowler è meglio eseguire test di unità veloci per ogni commit e test di integrazione e prestazioni lenti ogni poche ore .

    
risposta data 07.07.2014 - 23:10
fonte
2

What is the best way to get a grip on intended and unintended performance changes in such a setup?

Non so nulla della tua suite di benchmark, ma per quanto ne so io, questo può essere implementato come test automatico (presumo tu abbia già una suite di test con test di integrazione o di accettazione in atto). Quello di cui hai bisogno è

  • una possibilità di registrare i valori delle prestazioni in un formato leggibile dalla macchina

  • una possibilità di memorizzare i valori registrati come valori di riferimento

  • una possibilità di confrontare i valori registrati da "l'ultima esecuzione" con i valori di riferimento, e se tali valori differiscono "troppo", questo è un "test fallito".

Forse devi implementare queste tre cose usando alcuni script da soli, ma quando la tua suite di test consente l'esecuzione non eseguita, non dovrebbe essere troppo difficile.

Quindi, ogni volta che viene eseguita la tua normale suite di test (integrazione) (ad esempio, come parte di una "build notturna"), esegui anche la suite di test delle prestazioni e sarai informato sulle modifiche indesiderate nello stesso modo in cui verrai essere informato su qualsiasi altro test fallito.

Hai in mente che devi definire cosa significa "troppo". Tenete anche presente che l'esito dei risultati delle prestazioni può essere estremamente depurato dall'hardware, quindi quando dovete eseguire la suite di test su macchine diverse, o se il server di build sta lavorando su troppe altre cose in parallelo durante i test, aspettatevi i risultati saranno diversi.

Quindi prima di lanciare dei dati arbitrari sui dati per produrre dei grafici ben colorati, devi controllare manualmente dopo ogni analisi, verificare se è davvero appropriato per il tuo caso e se un sistema completamente automatico senza grafica non soddisfa le tue esigenze meglio.

Naturalmente, i grafici possono essere utili per analizzare la causa principale ogni volta che la performance diminuisce, ma solo per rilevare una deviazione eviterei tutto ciò che necessita di intercettazione manuale.

EDIT: rileggendo nuovamente la tua domanda, mi chiedo se stai utilizzando un server di build automatico o se al momento esegui tutte le build a livello locale. Se non si dispone di un server di build, questa potrebbe essere la prima cosa da cui iniziare (indipendentemente dai test delle prestazioni). Successivamente è possibile integrare alcuni test automatici su quella piattaforma e successivamente i test delle prestazioni. Se non si desidera configurare un tale sistema, la cosa minima di cui si ha bisogno è un singolo script che verificherà il codice sorgente completo in una directory pulita e compili tutto in un unico passaggio. Successivamente puoi provare ad integrare la corsa automatica dei test delle prestazioni. Ma immagino che un sistema server sia più appropriato, perché altrimenti bloccherete la vostra workstation per un certo periodo di tempo con ogni prova di funzionamento.

    
risposta data 08.07.2014 - 00:05
fonte
0

È possibile trovare qualche ispirazione su ciò che è possibile su questi dashboard delle prestazioni esistenti. Sfortunatamente, non tutti sono software libero, e nessuno di loro sembra essere pronto per l'uso da altri:

risposta data 09.07.2014 - 09:30
fonte