CdtFRMBenchmark

Test prestazioni del sistema

Scopo di questa maschera è effettuare un primo, incompleto test delle prestazioni dell'intero sistema. I risultati sono confrontati con quelli ottenuti in sede e ci danno un'indicazione dello stato di salute del sistema in cui si sta lavorando. Nota bene: nel caso in cui i risultati sono insoddisfacenti è necessario intervenire per migliorarli, viceversa dei risultati buoni non indicano necessariamente che il sistema è ben configurato e calibrato, ma solamente che quei test hanno dato buoni risultati.

Filtri

Sono presenti due tipi di filtri:

• Tipo: indica la tipologia di test da effettuare, in paticolare
  • Client CPU: Esegue dei test di calcolo e allocazione RAM sul client
  • Connessione cli-ser: Esegue dei test di trasferimento dati, o di chiamate tra client e server. E' la tipologia di test piu' pesante e diversificata, in particolare abbiamo
    • Chiamate al server senza traffico: misurano la latenza e non l'ampiezza di banda
    • Download: misurano la velocità di download dal server, richiedendo di volta in volta dati di varie dimensioni a seconda del singolo test
    • Upload: misurano la velocità di upload verso il server, inviando di volta in volta dati di varie dimensioni a seconda del singolo test
    • Pausa/senza pausa: ciascuno dei precedenti test può essere fatto in modalità con pausa o senza. Senza pausa una chiamata segue l'altra e quindi si va a saturare la banda di comunicazione (misurandola), con pausa invece si misura anche la latenza
  • Query DB: vengono eseguite alcune query sul DB. Queste non dipendono dai dati inseriti nel db stesso, in quanto esaminano tabelle precaricate da setup o tabelle create al volo, quindi l'esito dovrebbe essere lo stesso su un database vuoto o su uno pieno
  • Connessione JB-DB: testano la velocità di connessione tra JBoss e il database eseguendo query semplici ma che leggono moltissimi dati. Naturalmente se il database è mal configurato questi test danno un valore scarso, anche laddove la connessione JBoss-database sia ottima (per esempio perchè sono sullo stesso server)
  • Server CPU: Misurano la velocità di calcolo e la capacità di allocazione di memoria del server
• Evento: serve per eseguire un singolo test
• Veloce: esegue un decimo dei test previsti per velocizzare il processo. Tale risultato è ovviamente meno attendibile ma può servire in casi già critici dove il test, soprattutto di rete, potrebbe risultare lentissimo

Nota bene: Per i test di rete è necessario disattivare la compressione delle chiamate remote, altrimenti non hanno senso

Risultato

Il risultato è una griglia con le seguenti colonne:

• Descrizione: la descrizione del test
• Tempo medio: ogni test viene ripetuto un certo numero di volte, per avere una statistica, qui abbiamo il tempo medio dei test considerati validi
• N°: il numero di test ritenuti validi, i test i cui tempi sono all'interno del range media+/-*2*deviazione standard (Disuguaglianza di Tchebicheff)
• Tempo tot: il tempo totale impiegato dal test in millisecondi (escludendo i test scartati)
• Riferimento: il tempo totale ottenuto nella configurazione di riferimento ma rapportato al numero di esecuzioni valide. Quindi questo tempo può cambiare da un'esecuzione all'altra dei test
• Confronto: la % di confronto fra il tempo totale e il tempo di riferimento colorata:
  • Verde: tempo buono, uguale o maggiore alla configurazione di riferimento
  • Giallo: tempo mediocre, inferiore alla configurazione di rifemento ma non al 70%
  • Rosso: tempo pessimo, inferiore al 70% della configurazione di riferimento
• Best: il tempo migliore ottenibile (per esempio cambiando tipo di database)
• Tipo: il tipo di test, come descritto nei filtri
• Ambiente di riferimento: la descrizione dell'ambiente di riferimento in cui sono stati ottenuti i tempi di confronto

Considerazioni sui singoli test

• Query su dati modificati in una transazione: nel caso in cui questo test dia pessimi risultati (sono noti casi di valori inferiori all'1% dell'ambiente di riferimento) molto probabilmente dipende da una cattiva configurazione del log del database. Ricordiamo che:
  • I redo log di Oracle andrebbero su un disco diverso dai data file
  • Con SQL Server il file di log dovrebbe avere una dimensione iniziale piuttosto alta (almeno 500M) e un incremento in % di almeno il 10%