Appunti Impianti di elaborazione

Quinto Esempio: Supponiamo di misurare il throughput in due sistemi, A e B

Qual è il sistema migliore?

Se comparo le medie, il throughput medio è lo stesso.

Se voglio dire quanto A è più veloce rispetto a B:

Il sistema A normalizzato rispetto a B è più veloce di circa il 25%.

Se normalizzassi il sistema B rispetto ad A, otterrei la considerazione opposta, cioè che B normalizzato è più veloce di A.

Un benchmark può dire molto poco se non è collegato al workload tipico del sistema.

Al di là dei numeri, avremo a che fare con sistemi più complessi. Misurare un sistema complesso vuol dire avere misure di questo genere:

Ma le cose possono essere più complesse, ad esempio molto oscillanti:

In cui vediamo una zona di sovrapposizione.

Possono complicarsi ancora di più situazioni:

Non abbiamo un andamento unico, ma possiamo capire che il grafico è diviso in "epoche" (fasce).

punto di vista statistico: quando la differenza non è statisticamente significativa non è possibile esprimere nulla perché differiscono per i punti casuali. Quando modello il sistema, non devo modellare la parte casuale. In questo corso, dobbiamo capire come trattare le curve. Perché è importante nei sistemi di elaborazione tutto ciò? Perché nei sistemi di elaborazione complessi, abbiamo uno stack software con delle sorgenti di non determinismo (interrupt, scheduling): quando abbiamo sorgenti di non determinismo abbiamo una casualità. Spesso, nella valutazione delle prestazioni, si possono commettere una serie di errori. Ci sono tre problematiche principali nella valutazione delle prestazioni: l'obiettivo, il workload e la non conoscenza di tecniche statistiche fondamentali. Molte volte, può accadere di non avere un obiettivo ben preciso nella valutazione delle prestazioni; inoltre, talvolta, anche se si prefiggono degli obiettivi,

Non si tiene conto di un parametro fondamentale nell'avalutazione delle prestazioni, ossia il workload a cui il sistema è sottoposto. Molto spesso esistono degli errori comuni fatti durante la valutazione dei sistemi e sono quelli mostrati nell'immagine qui sotto. Ad esempio, la categoria del "No Goals" vuol dire che spesso si valutano i sistemi senza avere un obiettivo specifico, senza capire cosa si vuole ottenere.

Lo schema che si vede subito dopo invece mostra gli errori più comuni effettuati. Vediamo adesso in che modo scegliere una tecnica di valutazione tra le seguenti:

1. Tecniche di valutazione
   • Analytic modelling (teoria delle code)
   • Simulazioni
   • Misure sperimentali
2. Metriche di performance
3. Richiesta di prestazioni

Gli esperimenti sul campo non sempre sono buoni, ma sicuramente sono i più affascinanti, ma non è sempre vero che ci sia bisogno di sperimentare a causa dell'invasività. Come facciamo a capire, data una delle

Sono fatte su sistemi reali ed esistenti, sono costose in termini di tempo e soldi ma se fatte bene possono essere accurate. Abbiamo anche la difficoltà nel dettagliare per bene i risultati, ma ovviamente sono accurati poiché abbiamo il sistema realizzato.

Le tecniche hanno dei criteri per poter essere applicati, modelli analitici e simulativi li posso applicare ad ogni step del processo produttivo addirittura nella pratica quelli analitici li uso prima ancora. Il tempo richiesto dai modelli analitici è poco mentre per la simulazione dipende; per le misure dirette non so dire i tempi.

In tutto questo viene da sé che le misure dirette non sono applicabili senza modello reale, o almeno un prototipo.

Che strumenti servono? Un analista per fare modelli, nella simulazione ci vuole un linguaggio e chi fa misure dirette deve saper fare strumentazione.

Per l'accuracy dipende poiché ogni risultato può essere sbagliato o forviante. I costi sono in maniera crescenti.

Lemisure dirette non le devo mai privilegiare anche perché sono costose.Prima ci siamo fatti la domanda, data una tecnica, la uso come so che i risultati sono veritieri? È impossibile! Peravere almeno la correttezza dell’uso della tecnica uso la cross validation. Ma che vuol dire?Uso il modello simulativo, non mi fido dei suoi risultati fino a quando non uso quello analitico che me lo valida, poiquello a misure dirette. Una volta che li ho usati confronto i risultati dei tre!Si hanno tre regole di cross-validation:

1. Non affidarti ai risultati di una simulazione senza che essi siano validati anche da modelli analitici o misurazioni;
2. Non affidarti ai risultati di un modello analitico senza che essi siano validati anche dalla simulazione o dallemisurazioni;
3. Non affidarti ai risultati di una misurazione senza che essi siano stati validati anche dalla simulazione o dai modelloanalitici.

Quando faccio una misura diretta mi conviene sempre fare un piccolo modellino.

per capire se le misure appartengono al sistema o sono false. Su modelli analitici e simulativi o faccio la cross validation pura, cercare di vedere se le misure sono dello stesso ordine di grandezza dell'output dei modelli, o provo modelli analitici e simulativi con parametri misurati direttamente sul campo. In genere convince molto i clienti.

Lezione 3 (01.10.2021)

Che cosa sono le metriche di performance?

Quando parliamo di performance parliamo di tempo di risposta, throughput e utilizzo delle risorse.

Le metriche di dependability (metriche di affidabilità) come Availability (Disponibilità), Reliability, Performability.

Poi ci sono metriche che valutano compressi tra costi e prestazioni: i trade off sono a sensibilità dell'analista.

Vediamo come selezionare le metriche di prestazioni:

Abbiamo un sistema, e non ci interessa cosa rappresenta. Il sistema riceve una richiesta e deve elaborare e fornire una risposta: attenzione, la risposta può essere fornita, "done",

oppure non fornita, “cannot do”. Se la risposta fornita si assume corretta, possiamo parlare di performance: quindi la performance è relativa all’assunzione che il sistema funzioni (tempo di risposta, throughput e utilizzazione). Quando andiamo nell’altro caso, in cui forniamo una risposta scorretta, vuol dire che ci sono stati degli errori, allora determiniamo un altro dominio: la probabilità e il tempo tra un errore ed un altro.

Quindi, dato un sistema, a seconda di quello che voglio studiare, posso definire metriche diverse.

Ad esempio se vogliamo andare pacchetti da sorgenti a destinazione in modo ordinato: si possono verificare casi differenti:

1. Alcuni pacchetti sono consegnati in ordine alla destinazione corretta
2. Alcuni pacchetti sono consegnati ad una destinazione guasta
3. Alcuni pacchetti sono consegnati più volte (con dei duplicati)
4. Alcuni pacchetti sono droppati per strada (pacchetti persi).

Se ad esempio, andiamo a vedere le

metriche di performance, per la considerazione fatta prima, dobbiamo assumere che tutti i pacchetti vengano inviati in ordine. Nel momento in cui invece assumiamo che il sistema non funzioni, entrano in giochi concetti legati alla probabilità. Introduciamo indici particolari ma molto utilizzati: l’indice di fairness. Cosa succede quando più utenti richiedono l’utilizzo di una risorsa condivisa e gli utenti pagano per usufruirne in modo differente? Se ad esempio in un palazzo, abbiamo più utenti vodafone che richiedono gb diversi: molto probabilmente il throughput non è diviso equamente, allora chi è che ne sta usufruendo di più e chi di meno? Per capirlo si utilizza questo indice. Supponiamo che x è la frazione assegnata all’utente, mentre n è il numero di utenti a cui è affidato il sistema, allora l’indice di fairness si definisce come se questa quantità è uguale a 1, allora il sistema è

Lo scopo di questo indice è chiedersi: quello che stanno pagando i vari utenti è equo con quello che stanno utilizzando? Tale indice è super utilizzato quando si gestisce il cloud computing, si fornisce rete mobile o internet, etc.

Vediamo un esempio: supponiamo che 3 utenti, uno utilizza 50mega al secondo, il secondo 30 e il terzo 50. Supponiamo che paghino 50, 10, 10: il sistema è equo oppure no? È equo.

La normalizzazione è importantissima soprattutto quando compariamo le variabili in quanto riportiamo le grandezze sulla stessa scala: questa nella figura in alto è la normalizzazione più semplice. Una volta normalizzato andiamo a calcolare il nostro indice: Otteniamo quindi l'81% e quindi il sistema è abbastanza equo.

Il response time non è così semplice da misurare in alcuni contesti. Formalizzando abbiamo che è un parametro definito come: l'intervallo di tempo che intercorre tra la