Differenze tra le versioni di "CdtFRMBenchmark"
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%