Differenze tra le versioni di "CdtFRMBenchmark"

Da wiki.maggioli.it.
Jump to navigation Jump to search
imported>Arizzi
(Nuova pagina: = Test prestazioni del sistema = Scopo di questa maschera è effettuare un primo, incompleto test delle prestazioni dell'intero sistema. I risultati sono confrontati con quelli ottenu...)
imported>Atironi
 
(10 versioni intermedie di 2 utenti non mostrate)
Riga 2: Riga 2:


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.
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.
'''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.
I test si avviano dopo 5 secondi dalla pressione del tasto avvia in modo che sia possibile eseguirli anche in accesso remoto e chiudere il client dell'accesso remoto per non alterare i dati sul traffico di rete


== Filtri ==
== Filtri ==
Riga 13: Riga 16:
*** Upload: misurano la velocità di upload verso il server, inviando 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
*** 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. Impropriamente appartiene a questa categoria anche il test di lettura/scrittura su disco, che misura la velocità dei dischi del server JBoss, e non del server database se quest'ultimo è diverso
* 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 e dimensionati correttamente.
** Con SQL Server il file di log dovrebbe avere una dimensione iniziale piuttosto alta (almeno 500M) e un incremento in % di almeno il 10%

Versione attuale delle 10:46, 22 nov 2008

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.

I test si avviano dopo 5 secondi dalla pressione del tasto avvia in modo che sia possibile eseguirli anche in accesso remoto e chiudere il client dell'accesso remoto per non alterare i dati sul traffico di rete

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. Impropriamente appartiene a questa categoria anche il test di lettura/scrittura su disco, che misura la velocità dei dischi del server JBoss, e non del server database se quest'ultimo è diverso


  • 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 e dimensionati correttamente.
    • Con SQL Server il file di log dovrebbe avere una dimensione iniziale piuttosto alta (almeno 500M) e un incremento in % di almeno il 10%