MODELLISTICA DI IMPIANTI E SISTEMI 2

Транскрипт

1 MODELLISTICA DI IMPIANTI E SISTEMI 2

2 Indice 1 Dalla traccia al modello BAS I

3 Traccia Si consideri il problema della gestione efficiente dei servizi Internet, importante sia a livello di produttività personale che di business. In questo contesto, si consideri una tipica applicazione multi-tier che consiste di un Web server, un application server ed un back-end database. Ad esempio, nell ambito delle applicazioni di e-business, l accesso a un servizio Web avviene sotto forma di sessione che consiste di molte richieste individuali. Ordinare un prodotto via Internet, coinvolge ulteriori richieste quali selezionare un prodotto, fornire informazioni sulla spedizione, gestire il pagamento e finalmente ricevere una conferma. Dal punto di vista dell utente, la misura reale di prestazione del Web server, è la sua capacità di elaborare l intera sequenza di richieste necessarie per completare la transazione. Allo scopo, si consideri un meccanismo di controllo dell ammissione volto ad accettare una nuova sessione solo quando il sistema ha sufficiente capacità per elaborare tutte le future richieste collegate a quella sessione. In altri termini, solo quando il sistema può garantire il completamento con successo della sessione. Costruire un modello a rete di code del sistema oggetto dello studio. La richiesta per una nuova sessione, una volta accettata dal sistema, compie un accesso al front e al database server prima di tornare al client. Si noti che il Web server e l application server risiedono usualmente sullo stesso server fisico, perciò il sistema può essere modellato, ad eccezione dei centri necessari per modellare i client, da due centri a coda per il front ed il backend (database) server rispettivamente. Una volta che la richiesta ritorna al client, questo spende un think time prima di generare una nuova richiesta. Una sessione viene completata dopo che il client ha generato una serie di richieste. 1

4 1 Dalla traccia al modello Per modellizzare il progetto abbiamo analizzato inizialmente il testo cercando di identificare di quali centri avevamo bisogno. La versione embrionale di tale modello è rappresentata dalla seguente figura: Quello che si percepisce dalla precedente figura è che il sistema è composto da quattro elementi fondamentali: I client possono richiedere l esecuzione di una o più operazioni al server. Se un client richiede più operazioni al server allora ci troviamo di fronte ad una transazione. Prima di generare una nuova richiesta, il client spende un determinato think time. Nella precedente figura abbiamo rappresentato il comportamento dei client tramite un singolo centro di tipo rsrd, ovvero il centro C 1. Nella traccia è specificato che esiste un meccanismo che garantisce il completamento di una transazione del client. Pertanto nella precedente figura abbiamo inserito il centro C 2 che controlla la sessione dell utente. Tale centro possiede tempo di servizio nullo. Il server che possiede un architettura multi-tier, ovvero è composto da un Web server, un application server ed un database server. In questo caso il Web server e l application server girano sulla stessa macchina fisica. Pertanto abbiamo identificato un centro per il front-end ed un centro per il back-end, rappresentati rispettivamente dai centri C 3 e C 4 nella figura. Oltre alla presenza dei centri notiamo che sono presenti due probabilità ed un rettangolo che circonda i centri C 3 e C 4. Le due probabilità sono così descritte: P 1 : la probabilità che un utente non abbia una sessione già attiva. P 2 : la probabilità che un utente abbia una sessione già attiva, ovvero è pari a (1 P 1 ). Mentre il rettangolo ci ricorda che è presente un limite fisico del server multi-tier a smaltire le richieste dei client. Tuttavia questa soluzione possiede delle carenze. Innanzitutto nel centri C 2, C 3 e C 4 non abbiamo definito la tipologia dei centri C 2, C 3 e C 4. limitazione, ovvero all uscita del centro C 1 non possiamo sapere a priori se la transazione è finita o meno, quindi il modello è stato cambiato nel seguente modo: 2

5 3

6 1.1 BAS Il centro porta a termine il servizio e se il destinatario è saturo allora il centro si blocca. Quando il destinatario non sarà più saturo, dovrà avvertire i centri che sono bloccati su di lui tramite delle sveglie ed una politica di scheduling. Schematizzando abbiamo: Definizione BAS S i = (n i,b i, m i ) dove n i è il numero di job presenti nello stato i, b i può valere 1 o 0 in base al fatto che se lo stato è bloccato o meno ed m i rappresenta l array di sveglie ordinato in base ad una determinata politica. Per come è stato schematizzato il progetto abbiamo il seguente insieme di centri: {n 1,n 2,n 3,n 4,(n 5,b 5, m 5 )} Immaginiamo di stare nel nodo N 2. Se il nodo N 3 non accetta altri job nella sua coda, allora il job in uscita dal nodo N 2 viene bloccato. Supponiamo adesso che le code dei nodi N 2 ed N 3 siano sature. In questo caso bisogna: 1. attendere che il nodo N 3 si sblocchi, 2. mandare il job posto in attesa dal nodo N 2 al nodo N 3, 3. togliere il job più anziano dalla coda del nodo N 2 e processarlo, 4. mandare un allarme con la richiesta di accesso più vecchia o che possiede più priorità. Ovvero, se erano presenti delle richieste da N 5 allora un job presente nel nodo N 5 entra nella coda del nodo N 2, altrimenti entrerà un job del nodo N 1. Quindi tale operazione sblocca il nodo mittente. 4