Gerarchie di benchmarks

Dimensione: px

Iniziare la visualizzazioe della pagina:

Download "Gerarchie di benchmarks"

Guido Lupi
5 anni fa
Visualizzazioni

1 Lezione 6

4 Gerarchie di benchmarks grana grossa grana fine Synthetic Benchmark: Dhrystone Toy Benchmark : Crivello di Eratostene, Torre di Hanoi Kernel Benchmark: Limermooe loop, Linpack Full Scale, real program (SPEC, TPC)

5 Gerarchie di Benchmark

6 Attenti agli errori! comprendere il contesto assicurarsi dell adeguatezza assicurarsi che il workload sia idoneo Un benchmark deve essere rilevante per lo specifico dominio facile da comprendersi Scalabile Accettabile sia dagli utenti che dai venditori Il consorzio SPEC ( System Performance Evaluation Corporation) TPC Transaction Processing Performance Council TPC-C, TPC-H, TPC-R, TPC-W

BENCHMARK dei Processors SPEC xxxx contiene la suite int e quella fp la fp contiene 14 applicazioni in FORTRAN o in C la int, es SPEC CINT2000 misura gli

7 BENCHMARK dei Processors SPEC xxxx contiene la suite int e quella fp la fp contiene 14 applicazioni in FORTRAN o in C la int, es SPEC CINT2000 misura gli interi e si compone di 12 applicazioni in C e C++ La macchina di riferimento è la SUN Ultra SPARC 5-10 alla quale è assegnato un valore di riferimento pari a100

11 Un esempio di risultato di SPECweb 99

Si Misurano La latenza di connessione e la latenza di servizio

factor ( LLF) che indica il grado di concorrenza - cioè il numero

altro che la formula di little considerando l webserver come una

13 Si Misurano La latenza di connessione e la latenza di servizio Webstone fornisce medie e varianze Webstone presenta il Little s load factor ( LLF) che indica il grado di concorrenza - cioè il numero medio di connessioni aperte in un particolare istante del test Non è altro che la formula di little considerando l webserver come una black box Numero di connessioni medie = Tasso di connessione x tempo medio di risposta

14 Generatori di workload basati su espressioni analitiche trace based Il tool che usa generatori analitici è SURGE basando si su due concetti: user equivalent modelli di distribuzione Un user equivalent è un processo in un loop senza fine che alterna richieste HTTP a stati di Idle. La load intensity può essere misurata in termini di user equivalent. Le distribuzioni in gioco: P[ X > x] ~ x α con 0 < α 2 Gli utenti possono definire la location e i parametri di scaling Lo scaling stira o comprime la PDF, la location la sposta sugli assi cartesiani

15 Quali distribuzioni si usano? Dimensione dei File: si possono modellare con due distribuzioni la logonormale per il corpo della distribuzione e la Pareto per la coda Distribuzione Logonormale: p(x) = 1 xσ 2π e (ln x µ) 2 /2σ 2 è il parametro che caratterizza la forma è il parametro della locazione Distribuzione di Pareto: p(x) = αk α x (α+1)

16 Dimensione della richiesta : PARETO Popolarità: La misura della distribuzione delle richieste in termini di numero di files Legge di ZIPF Il numero di riferimenti alla pagina P, N(P) tende ad essere inversamente proporzionale al suo rango r(p) N(P) = kr (P) -1 Riferimenti ad oggetti embedded: Il numero di essi -> PARETO Località temporale: un oggetto acceduto frequentemente nel recente passato molto probabilmente sarà acceduto ancora nel prossimo futuro Un modo per misurarlo è la Stack distance il numero di riferimenti ad oggetti tra due riferimenti ad uno stesso oggetto. Ovviamente valori piccoli indicano riferimenti frequenti. La miglior distribuzione è la Logonormale OFF TIME tempi di idle dei processi che generano richieste- due tipi: think time -> PARETO tempo tra trasferimenti di componenti in un singolo oggetto ( browser parsing formatting etc. Questo secondo tipo si modella con la Weibull Distribution b 1 bx b p(x) = a b e ( x / a)

17 SURGE soddisfa a tutti i requisiti delle distribuzioni delle 6 carateristiche del workload del web Fornisce un singolo stream di output delle richieste che combina opportunamente le distribuzioni Il traffico risultante delle richieste generate è Self Similar esibisce notevole variabilità su varie scale temporali. Recentemente sono apparsi i primi generatori di sequenze self similar: P. Inacio, B.Lakic, M.Freire, M. Pereira, P. Monteiro The design and evaluation of the simple self similar sequence generator Information Science Elsevier 179 ( 2009)

20 Metriche del TPC-W Throughput metric Cost/throughput metric WIPS (Web Interaction Per Second) Throughput in funzione di un valore di scala : Numero degli elementi del catalogo. WIPSb; WIPSo; $/WIPS

21 PERFORMANCE TESTING generare attività di sistema e imitare il comportamento degli utenti Simulare l ambiente di produzione e gli scenari di workload con lo scopo di ottenere risultati quanto più accurati possibili. I test vanno pianificati in modo da prevedere le azioni da mettere in atto per rimuovere eventuali problemi che emergono durante il test Tipi di test stato stazionario peak load Load testing in regime normale di funzionamento Stress testing caso peggiore, massimo carico prevedibile Spike testing carico estremamente elevato per brevi periodi di tempo analoghi agli spike tipici del web traffico peer to peer distinzione tra p2p & web

22 Metodologie per test di performance Determina la capacità del server Web. Determina il max numero di utenti concorrenti. Determina la capacità dell application layer. Identifica i colli di bottiglia nell infrastruttura web. Identifica l impatto della rete sul response time percepito dagli utenti. Determina la capacità del Server DB. Identifica le funzioni Web più dispendiose.

23 determinare quale genere di infrastrutture, software, middleware network connectivity, net protocol sono presenti Determinare - stati stazionari e situazioni di picco, eventuali spike e SLA

24 - web service and function - scenari (ottimistico e pessimistico) - SLA - running test

25 Caratterizzare il comportamento degli utenti

26 Manual testing Automatic testing I test dovrebbe essere condotti da un team sotto la supervisione del project manager

Lo step più importante - si determinano i luoghi dei colli di bottiglia che causano problemi di performance o rappresentano ostacolo alla crescita del numero degli utenti concorrenti.

27 Lo step più importante - si determinano i luoghi dei colli di bottiglia che causano problemi di performance o rappresentano ostacolo alla crescita del numero degli utenti concorrenti. Non è sempre vero che aggiungendo hardware i problemi si risolvono. Spesso sono problemi di dimensionamento, di tuning. E importante verificare che le misure siano coerenti - l uso dell analisi operazionale aiuta a verificare la consistenza dei dati.

Documenti analoghi

METRICHE E MODELLI DI INTERNET

METRICHE E MODELLI DI INTERNET a.a. 2012/13 Lezione 6 Salvatore Tucci Emiliano Casalicchio Università di Roma Tor Vergata Dipartimento di Informatica Sistemi e Produzione Computer Engineering & Internet