Luca Cabibbo Architettura dei Sistemi Software dispensa asw220 marzo 2019 An ounce of performance is worth pounds of promises. Mae West 1 - Fonti [SAP] Chapter 8, Performance [SSA] Chapter 26, The Performance and Scalability Perspective Liu, H.H. Software Performance and Scalability: A Quantitative Approach. Wiley, 2009. 2
Obiettivi - Obiettivi e argomenti presentare la qualità delle prestazioni illustrare alcune attività e tattiche per la progettazione per le prestazioni fare qualche considerazione generale sulla progettazione per gli attributi di qualità poiché questa è la prima qualità che viene presa in considerazione Argomenti prestazioni progettare per le prestazioni discussione 3 * (performance) la capacità del sistema di eseguire in modo prevedibile entro il profilo di prestazioni richiesto Le prestazioni hanno a che fare con il tempo ovvero, con la capacità di un sistema di soddisfare dei requisiti temporali le prestazioni misurano quanto velocemente un sistema software può completare alcuni compiti di elaborazione [Liu] in generale, si vuole che un sistema abbia delle prestazioni adeguate (rispetto ad un profilo di prestazioni richiesto) come per tutte le qualità, non è dunque sempre necessario che il livello delle prestazioni sia elevato o eccezionale attenzione, il dizionario Treccani definisce il (bruttissimo) aggettivo performante come che offre prestazioni di ottimo livello che, dunque, non è in genere l obiettivo desiderato 4
In alcuni sistemi, progettare per le prestazioni è importante anche perché le prestazioni possono avere un impatto su altre qualità del sistema ad es., un sistema con prestazioni scarse può essere considerato poco responsive e dunque poco usabile inoltre, la progettazione per le prestazioni è in genere propedeutica alla progettazione per la scalabilità (che discuteremo in una successiva dispensa) 5 6 Tipi di compiti e metriche per le prestazioni Due tipi principali di compiti computazionali e le relative metriche principali per le prestazioni transazioni online di tipo interattivo il tempo di risposta (o latenza) è il periodo di tempo richiesto per completare l esecuzione di un operazione o la gestione di un evento job non interattivi, di tipo batch il throughput è il numero di job o transazioni che il sistema è in grado di completare in un unità di tempo esistono anche altre metriche (che qui non consideriamo) ad es., il jitter (la variabilità del tempo di risposta) o il numero di eventi non processati (perché il sistema era troppo impegnato per poter rispondere) Qui ci concentriamo soprattutto sulla gestione di eventi e sul tempo di risposta richiesto per gestire un evento
Scenari per prestazioni 7 In genere, uno scenario per le prestazioni descrive quanto velocemente il sistema deve rispondere ad una tipologia di eventi gli eventi possono essere richieste, messaggi o eventi temporali di un certo tipo ad es., la richiesta di esecuzione di un operazione di sistema da parte di un utente o client del sistema uno scenario per le prestazioni specifica il tipo di eventi di interesse la distribuzione degli arrivi di questi eventi la risposta temporale richiesta di solito, le tattiche per le prestazioni vanno prese in considerazione quando ci sono uno o più scenari per le prestazioni in cui la risposta temporale prevista (nell architettura attuale) è inadeguata rispetto a quella richiesta dunque, quando è necessario ridurre il tempo di risposta di una o più operazioni - Considerazioni sulle prestazioni Ci sono due contributi principali al tempo di risposta a un evento il tempo di elaborazione e il tempo di attesa tempo di elaborazione il tempo effettivamente dedicato a generare la risposta all evento, in cui vengono consumate risorse computazionali comprende, ad es., il tempo di CPU, per l accesso ai dati in memoria o sul disco, e per la comunicazione in rete tra elementi distribuiti 8
Considerazioni sulle prestazioni Ci sono due contributi principali al tempo di risposta a un evento il tempo di elaborazione e il tempo di attesa tempo di attesa il tempo in cui la computazione è bloccata in attesa qualche risorsa questo può accadere per diversi motivi perché è necessaria una risorsa che è già impegnata ma può essere usata da un singolo elemento alla volta perché la risorsa non è disponibile per un guasto o perché è temporaneamente fuori linea per attendere il risultato di un altra computazione che non è stata ancora completata ad es., per una necessità di sincronizzazione tra computazioni diverse intuitivamente, il tempo di risposta può essere ridotto intervenendo su uno, sull altro o su entrambi questi contributi 9 Considerazioni sulle prestazioni Altre considerazioni sulle prestazioni le prestazioni dipendono anche dall hardware utilizzato, dalla sua capacità e quantità, e dal suo livello di utilizzazione l hardware è costoso, va gestito, e potrebbe non essere possibile sostituirlo facilmente le prestazioni di un sistema dipendono anche dal suo carico di solito variano in modo non lineare con il carico in particolare, le prestazioni del sistema possono degradare rapidamente all approssimarsi di un certo livello di carico in generale, ciò avviene quando il livello di utilizzazione di una qualche risorsa del sistema (chiamata collo di bottiglia) si avvicina alla sua capacità (ovvero, la risorsa è satura) il comportamento di questa risorsa peggiora più o meno all improvviso e fa degradare le prestazioni dell intero sistema 10
Considerazioni sulle prestazioni Altre considerazioni sulle prestazioni nella progettazione per le prestazioni è necessario considerare la possibilità di eseguire computazioni in modo concorrente la concorrenza ha in genere effetti benefici sulle prestazioni se più attività possono essere effettivamente svolte in parallelo ma richiede anche di considerare tutte le implicazioni della concorrenza l accesso e la contesa di risorse condivise la necessità di sincronizzazione tra le computazioni 11 * Progettare per le prestazioni Alcune attività nella progettazione per le prestazioni [SSA] specificare gli scenari e i requisiti più significativi per le prestazioni e assegnargli delle priorità creare e valutare modelli per le prestazioni ad esempio, modelli basati sulle reti di Petri e sulla teoria delle reti di code questi modelli possono essere valutati mediante dei simulatori forniscono informazioni sia sulle prestazioni attese che sul livello di utilizzazione delle risorse realizzare e verificare praticamente dei prototipi e anche il sistema stesso utilizzare strumenti di monitoraggio di sistema e API per la profilazione analizzare i risultati della valutazione raffinare l architettura 12
- Tattiche per le prestazioni [SAP] propone due categorie principali di tattiche per le prestazioni per migliorare il tempo di risposta a un evento tattiche per controllare la richiesta di risorse control resource demand cercano di ridurre il tempo dedicato alla gestione di un evento, dal lato della richiesta delle risorse che sono necessarie per elaborare l evento ad es., migliora l algoritmo tattiche per gestire le risorse manage resources operano dal lato dell offerta delle risorse, per gestire le elaborazioni in modo più efficace ad es., usa un processore più potente 13 - Control resource demand Tattiche per ridurre la richiesta di risorse per elaborare un evento Increase resource efficiency (Improve algorithm efficiency) l elaborazione di un evento richiede l esecuzione di un algoritmo un miglioramento dell efficienza temporale di questo algoritmo, soprattutto nelle aree più critiche, diminuisce il tempo di risposta talvolta si può migliorare l efficienza temporale scambiando tempo con un altra risorsa ad es., memorizzare risultati intermedi per evitare un loro successivo ricalcolo 14
Control resource demand Tattiche per ridurre la richiesta di risorse per elaborare un evento Reduce overhead l uso di intermediari aumenta le risorse consumate nell elaborazione di un evento l eliminazione di qualche intermediario può ridurre il tempo di risposta esempi di intermediari che provocano un overhead sono la comunicazione interprocesso e di rete, la trasformazione del formato dei messaggi, la cifratura,... poiché questi intermediari sono spesso importanti per sostenere altre qualità, spesso è necessario trovare dei compromessi 15 Control resource demand Altre tattiche per ridurre la richiesta di risorse hanno lo scopo di migliorare il tempo di elaborazione riducendo la quantità di elaborazione da svolgere ma questo non sempre è accettabile o possibile limitare il tempo di elaborazione di un evento ad es., calcolando un risultato approssimato anziché esatto ridurre la frequenza degli arrivi al sistema ad es., la frequenza di campionamento da un certo sensore ignorare alcuni eventi dalla coda delle richieste ad es., gestendo una coda degli eventi e limitandone la lunghezza assegnare priorità agli eventi per poter poi decidere di scartare degli eventi a bassa priorità quando le risorse iniziano a scarseggiare 16
- Osservazioni Prima di andare avanti nell illustrazione di altre tattiche, è utile fare alcune osservazioni applicabilità delle tattiche non sempre è possibile o accettabile applicare tutte le tattiche a disposizione applicazione delle tattiche l applicazione di una tattica può avere effetto su uno o più elementi architetturali e/o su una o più relazioni tra elementi architetturali in una o più viste architetturali ad es., increase resource efficiency ha effetto sulla caratterizzazione esterna di un operazione di un elemento architetturale ad es., reduce overhead può cambiare la scelta di alcuni elementi architetturali oppure della loro interconnessione 17 Osservazioni Prima di andare avanti nell illustrazione di altre tattiche, è utile fare alcune osservazioni effetto qualitativo e quantitativo delle tattiche l applicazione di una tattica può portare a controllare nel modo desiderato un certo attributo di qualità ad es., ridurre il tempo di risposta qui ci limitiamo a dare delle intuizioni circa l effetto qualitativo delle tattiche in alcuni casi è possibile fare anche ragionamenti quantitativi sull effetto dell applicazione di una tattica ma qui non lo faremo detto in altro modo, qui stiamo facendo affermazioni solo sulla direzione dell effetto dell applicazione di una tattica, ma non sulla sua quantità ma considerazioni quantitative sono spesso possibili ed effettivamente necessarie 18
Osservazioni Prima di andare avanti nell illustrazione di altre tattiche, è utile fare alcune osservazioni tattiche ed effetti collaterali l applicazione di una tattica ha di solito effetti benefici su un attributo di qualità ma può anche avere effetti collaterali (negativi oppure positivi) su altri attributi di qualità la progettazione dell architettura è spesso basata su compromessi (trade-off) tra decisioni architetturali questa trattazione descrive solo alcuni dei possibili effetti collaterali delle tattiche mostrate 19 Osservazioni Prima di andare avanti nell illustrazione di altre tattiche, è utile fare alcune osservazioni quando è necessario applicare una tattica? non è utile applicare una tattica se il corrispondente attributo di qualità è già ben controllato pertanto sono utili tecniche per la valutazione dell architettura per capire in che misura viene controllata ciascun attributo di qualità e se gli obiettivi di qualità complessivi del sistema sono raggiunti o meno 20
- Manage resources Tattiche per la gestione delle risorse anche una gestione migliore delle risorse può portare a una riduzione del tempo di risposta Increase resources risorse (processori, memorie, reti,...) addizionali o più veloci hanno il potenziale per ridurre il tempo di risposta è la tattica più semplice a fronte di un ovvio aumento dei costi 21 Manage resources Tattiche per la gestione delle risorse basate sulla concorrenza intuitivamente, ci sono almeno due modi diversi per applicare la concorrenza suddividi l elaborazione di un evento in più compiti distinti, da eseguire in modo concorrente (Introduce concurrency) gestisci eventi distinti in modo concorrente (Maintain multiple copies of computations) 22
Manage resources Tattiche per la gestione delle risorse basate sulla concorrenza Introduce concurrency questa tattica suggerisce di suddividere l elaborazione relativa alla gestione di un singolo evento in più compiti distinti, da svolgere in parallelo e in modo concorrente ad es., usando thread diversi per svolgere attività differenti poiché ciascun compito richiede meno risorse che non quelle necessarie per gestire l intero evento, questo può ridurre il tempo di attesa in questo caso, la concorrenza è usata nella gestione di un singolo evento 23 Manage resources Tattiche per la gestione delle risorse basate sulla concorrenza Maintain multiple copies of computations questa tattica suggerisce di replicare risorse computazionali per consentire l elaborazione di più eventi distinti, da svolgere in modo concorrente ad es., replicare un componente server usare un thread diverso per ciascun evento concorrente oppure, replicarlo su più processi o nodi di calcolo questo può richiedere anche l introduzione di un meccanismo di bilanciamento del carico (load balancer) la replicazione delle risorse ha lo scopo di ridurre la contesa in questo caso, la concorrenza è usata per la gestione di un insieme di eventi concorrenti tra di loro 24
Manage resources Tattiche per la gestione delle risorse Maintain multiple copies of data è anche possibile replicare dei dati, e consentirne l accesso in modo concorrente ad es., mediante meccanismi di data replication o di caching poiché esistono più copie degli stessi dati, potrebbe essere necessario assegnare della responsabilità aggiuntive (cioè, non inizialmente presenti) per mantenere opportunamente consistenti e sincronizzate le varie copie di ciascun dato replica e copia non vanno sempre intesi in modo letterale ma possono essere intesi anche come dati ridondanti, anche rappresentati in forme diverse ad es., alcuni dati potrebbero essere rappresentati in una forma adatta alle interrogazioni e una adatta agli aggiornamenti 25 Manage resources Altre tattiche per la gestione delle risorse schedulare l uso delle risorse in caso di contesa di risorse, l arbitraggio e la schedulazione delle risorse può consentirne un loro utilizzo più efficiente è ad esempio possibile schedulare processori, buffer e reti sono possibile diverse strategie ad es., FIFO, fixed priority, dynamic priority, static scheduling adatte a situazioni diverse limitare la dimensione delle code questa tattica controlla il numero massimo di eventi posti in coda comunemente usata con la tattica che suggerisce di ignorare alcuni eventi dalla coda delle richieste bisogna gestire la responsabilità di decidere cosa fare in caso di trabocco delle code 26
Tattiche per le prestazioni Sintesi delle principali tattiche per le prestazioni di [SAP] event arrives Performance response generated within time constraints Control Resource Demand Manage Resources reduce overhead increase resource efficiency increase resources introduce concurrency maintain multiple copies of computations maintain multiple copies of data 27 - Altre opzioni di progettazione per le prestazioni Ecco alcuni ulteriori suggerimenti, tattiche e opzioni di progettazione per le prestazioni proposti nel contesto (più ampio) della prospettiva delle prestazioni e della scalabilità di [SSA] 28
Altre opzioni di progettazione per le prestazioni Ottimizza le elaborazioni ripetute molti sistemi hanno un piccolo numero di operazioni comuni su cui il sistema spende la maggior parte del tempo la progettazione per le prestazioni deve concentrarsi soprattutto su queste operazioni Riduci la contesa tramite replicazione la contesta di risorse condivise è spesso una causa significativa di problemi per le prestazioni di operazioni che devono essere eseguite in modo concorrente una soluzione comune (ma non sempre possibile) a questa contesta è la replicazione di risorse in particolare, è possibile replicare sia risorse di elaborazione che dati/risultati Maintain multiple copies of computations e Maintain multiple copies of data 29 Altre opzioni di progettazione per le prestazioni Partiziona e parallelizza per ridurre il tempo complessivo di esecuzione di elaborazioni particolarmente lunghe Introduce concurrency Altre tattiche che suggeriscono di ridistribuire l elaborazione nel tempo assegna priorità alle elaborazioni posticipa l esecuzione di attività meno importanti a momenti di carico minore per il sistema consolida carichi di lavoro correlati in modo da ottimizzare lo svolgimento di attività comuni a un certo insieme di operazioni 30
Altre opzioni di progettazione per le prestazioni Usa elaborazioni asincrone ovvero, decomponi l elaborazione in attività concorrenti che possano procedere con necessità deboli di sincronizzazione in genere, il consumo complessivo di risorse è minore quando viene usata la comunicazione asincrona anziché sincrona Altre tattiche che suggeriscono di ridurre le necessità di sincronizzazione minimizza l uso di risorse condivise ad es., favorisci transazioni brevi per minimizzare il tempo in cui vengono accedute e bloccate delle risorse condivise rilassa i requisiti di consistenza transazionale ad es., da strict consistency a eventual consistency 31 * Discussione Le prestazioni riguardano la capacità di un sistema di soddisfare dei requisiti temporali abbiamo discusso alcune attività legate alla progettazione per le prestazioni sono state presentate alcune tattiche architetturali e opzioni di progettazione per le prestazioni alcune di queste tattiche e opzioni di progettazione sono propedeutiche alla progettazione per la scalabilità Ciascuna tattica è una decisione di progetto per controllare un certo attributo di qualità l applicazione di una tattica ha impatto sull architettura ovvero, sulla scelta degli elementi, delle loro responsabilità, o di come sono messi in relazione e su come l architettura sostiene le qualità la presentazione è stata qualitativa e informale 32