Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Capitolo 10
Progettazione dell’architettura
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
IndiceINDICE
• Introduzione
• Valutazione delle architetture
• Configurazioni architetturali
• Ottimizzazione delle prestazioni
• Web caching
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Valutazione delle architetture
INTERNET
• Ogni scelta architetturale va valutata in base a dimensioni critiche:
• Obiettivo di un’architettura: massimizzare queste dimensioni
•Prestazioni
•Scalabilità
•Disponibilità
•Mantenimento dello stato
•Sicurezza
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Obiettivi (1)
INTERNET
• Prestazioni: garanzia di sopportazione del carico di lavoro previsto, in termini di:– N° utenti concorrenti– N° pagine servite/secondo– Tempo di risposta all’utente
• Scalabilità: possibilità di aggiungere potenza computazionale al crescere del carico di lavoro, per mantenere elevate prestazioni
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Obiettivi (2)
INTERNET
• Disponibilità: garanzia di continuità del servizio anche a fronte di errori e/o malfunzionamenti
• Mantenimento dello stato: capacità di memorizzazione delle interazioni e dello stato dell’utente, anche in ambiente distribuito
• Sicurezza: protezione delle informazioni, identificazione dell’utente, accesso controllato ai dati
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Vincoli:limitazioni nella scelta
INTERNET
• Le scelte architetturale sono vincolate da limiti fisici, economici ed organizzativi:•Costi: il prezzo delle risorse tecnologiche richieste (macchine, reti, software)
•Complessità: difficoltà e costi di installazione, gestione e manutenzione
•Standard aziendali: risorse pre-esistenti, esperienza pregressa, integrazione con i sistemi aziendali
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Scenari di installazione
INTERNET
• Tendenza generale: OUTSOURCING.
• Possibili scenari:•Interno: architettura interna all’azienda, gestita dalla divisione IT
•Hosting: applicazione installata su architettura di provider esterno, che la gestisce completamente
•Housing: applicazione installata internamente su macchine aziendali, gestita poi da un fornitore di servizi esterno
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
I componenti essenziali dell’architettura:
INTERNET
ScriptEngine
Scripts
ClientsComponents
Container
Components
ApplicationServer
Web Server
Databasemanagement
systems
•Web ServerWeb Server
•Script EngineScript Engine
•Application Application ServerServer
•Database ServerDatabase ServerScelte architetturali per decidere:
•Quali componenti vanno su macchine separate
•Quante macchine servono per ogni componente
•Come collegare tra loro componenti
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Configurazione 1: SERVER SINGOLO
INTERNET
•Una sola macchina (Host 1) ospita:
•Web Server
•Script execution engine
•Database
Client(browser)
Internet Intranet
° Web server
° Execution engine
° Database
Host 1
Router /firewall
HTTPHTTP
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Il router/ firewall
• Router: – Punto di connessione Internet/ Intranet– Consente a browser esterni di
connettersi al Web Server
• Firewall:– Separa il mondo esterno (Internet) dalla
rete aziendale (Intranet)– Blocca i tentativi di intrusione e le
richieste non autorizzate (attraverso Access Control Rules)
• Può essere un unico dispositivo che svolge le due funzioni
Router /firewall
Internet Intranet
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
SERVER SINGOLO: valutazione
INTERNET
•Prestazioni: legata alle caratteristiche della macchina (velocità CPU, HDD, connessione di rete, DBMS).
•Criticità: Database e Web Server sulla stessa macchina. Sono due processi che occupano molte risorse (RAM, tempo-CPU)
•Scalabilità: unica possibilità è upgrade della macchina (aggiunta RAM, cambio CPU o dischi, …)
•Disponibilità: se cade un componente, tutto il sistema è fermo
•Mantenimento dello stato: semplice perché su macchina singola (memorizzato nello script engine e/o nel database)
•Sicurezza: dati non difesi se il firewall viene superato
•Costo: basso, se non serve hw ad alte prestazioni
•Complessità: soluzione più semplice da installare e mantenere
° Web server
° Execution engine
° Database
Host 1
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Config. 2: SEPARAZIONE DEL DB SERVER
INTERNET
•Web Server e Script execution engine sono ospitati su una macchina (Host 1)
•Il Database Server è ospitato su un altro calcolatore (Host 2)
•L’aggiunta di un firewall intermedio aumenta la sicurezza dei dati
Client(browser)
Internet
Router /firewall
HTTPHTTP
Web server +Execution engine
Host 1
Database
Host 2
Intranet
Firewall
Demilitarized zone (DMZ)
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
SEPARAZIONE DEL DB: valutazione
INTERNET
•Prestazioni: dimensionamento migliore delle due macchine
•Es.: potenziamento accesso/mirroring dei dischi del DB server
•Scalabilità: possibilità di intervenire separatamente su middle tier e data tier
•In genere è il middle tier che raggiunge per primo la saturazione; richiede potenziamento per appieno le potenzialità del data tier
•Disponibilità: un componente fermo blocca ancora il sistema
•Sicurezza: dati su macchina separata sono più sicuri; un firewall tra middle e data tier può bloccare le richieste HTTP (attacchi) e consentire solo le richieste al DB
Web server +Execution engine
Host 1
Database
Host 2
Intranet
Firewall
Demilitarized zone (DMZ)
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
REPLICAZIONE E PARALLELISMO
INTERNET
•prestazioni
•disponibilità
•scalabilità
sono limitate dalla presenza di
UNA SINGOLA ISTANZA DI OGNI COMPONENTE
Soluzione: REPLICAZIONE
•Replico i processi critici (Web Server, script engine,…)
•Tengo in esecuzione più copie in parallelo di ogni processo
Engine
Engine
Engine
Engine
Replicazione : applicabile a qualsiasi livello dell’architettura
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Replicazione orizzontale e verticale
INTERNET
•VERTICALE: una singola macchina server ospita più istanze di processo
Vertical cloning
Host 1:
Process 1
Process 2
Process 3
Process 4
Horizontal cloning
Host 1:
Process
Host 2:
Process
Host 3:
Process
Host 4:
Process
Due modi di fare replicazione di applicazioni:
•ORIZZONTALE:L’intera macchina server viene replicata. Ogni macchina ospita una o più istanze di processo
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Vantaggi della replicazione INTERNET
•Prestazioni consente LOAD-BALANCING: distribuzione del carico di lavoro sui server/ processi in modo bilanciato
•ScalabilitàSe necessario, è possibile aggiungere nuove istanze di processi (o macchine server, in cluster)
•Disponibilitàconsente FAIL-OVER: se cade uno dei processi, il suo carico di lavoro viene distribuito sui processi funzionanti e il sistema continua a fornire il servizio
Indipendenti dal tipo di replicazione (orizz. o vert.)
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Config. 3: REPLICAZIONE DEL WEB SERVER
INTERNET
•Più copie del Web Server funzionanti in parallelo
•Router/firewall fa da NETWORK DISPATCHER (bilancia il carico di lavoro tra i diversi Web Server)
•Alcuni server possono usare SHTTP per garantire la sicurezza: il dispatcher invia tutte le richieste SHTTP al server sicuro
Client(browser)
Internet
Router /firewall
HTTP
Database
Host 2
Intranet
Firewall
HTTP
HTTP
SHTTP
Web server + engine 1
Web server + engine 2
Web server + engine 3DMZ
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Router /firewall
HTTP
HTTP
HTTP
SHTTP
Il problema delle sessioni utente
INTERNET
•Bisogna garantire che lo stato dell’utente sia mantenuto
SUL LOAD-BALANCING:
•STICKY SESSION: Tutte le richieste dello stesso client devono essere inviate dal dispatcher allo stesso server (lo stato utente è memorizzato sul server!)
•Il dispatcher deve avere una certa “intelligenza” per riconoscere le richieste di uno stesso utente. Non basta l’IP del client: potrebbe essere usato da più utenti di una intranet
SUL FAIL-OVER:
•Le sessioni memorizzate dal Web server guasto devono essere recuperate ed usate dagli altri Web server (che riceveranno le richieste seguenti degli utenti connessi al server guasto)
•I dati di sessione devono essere memorizzati in modo duraturo (es. nel DB) [Soluzione costosa per le prestazioni]
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Popolazione della cache: metodo pull
PULL:• La copia in cache avviene nel momento in cui una
richiesta del client scatena un avviso di assenza da cache
• Usato più spesso
Cache
Avviso diassenza da
cache
Aggiornamentodella cache
Richiesta
Risposta dacache Server
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Protocolli di gestione della cache• Protocolli che raccolgono regole per
l’aggiornamento della cache:– Expiration rules: definiscono la durata della validità di
un oggetto in cache– Invalidation rules: criteri per stabilire se l’oggetto in
cache non è conforme con l’originale corrente
• Sono molto complessi per risorse dinamiche• E’ possibile inserire delle direttive di caching
nelle risorse dinamiche (per esempio mediante custom tag nelle pagine JSP)
• Proposta di standard: Edge Side Include (ESI) www.esi.org
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
REPLICAZIONE DEL WEB SERVER: valutazione
INTERNET
•Prestazioni: più elevate grazie al load-balancing
•Scalabilità: possibilità di aggiungere nuovi Web server
•Disponibilità: se cade un Web server, il suo traffico è ridiretto su una sua replica
•Mantenimento dello stato: necessari meccanismi sticky session e memorizzazione stato per il fail-over
•Sicurezza: possibilità di avere uno o più server sicuri
•Complessità: accresciuta dalla replicazione
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Configurazione 4: CON APPLICATION SERVER
INTERNET
•Centralizzazione della business logic nell’App. Server mediante oggetti riusabili (per esempio, Enterprise Java Beans, componenti MS DCOM)
•Gli oggetti possono essere invocati da qualunque applicazione aziendale (anche non Web)
•La gestione di parallelismo, replicazione, sicurezza, disponibilità è garantita dall’application server ed è trasparente al programmatore
Client(browser)
Internet
Router /firewall
HTTP
Database
Host 2
Intranet
Firewall
HTTP
HTTP
SHTTP
DMZ
WebServer1 Engine 1
WebServer2 Engine 2
WebServer3 Engine 3Application
server
Applicationserver
Applicationserver
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Configurazione 4: CON APPLICATION SERVER
INTERNET
•Bilanciamento e failover a livello degli oggetti applicativi
•Parallelismo DINAMICO: il numero di processi allocati e di istanze di oggetti è scelto a run-time in base al traffico reale
•Possibilità di effettuare catene di operazioni sugli oggetti in modo transazionale
•Application server isolabile con un ulteriore firewall
Client(browser)
Internet
Router /firewall
HTTP
Database
Host 2
Intranet
Firewall
HTTP
HTTP
SHTTP
DMZ
WebServer1 Engine 1
WebServer2 Engine 2
WebServer3 Engine 3Application
server
Applicationserver
Applicationserver
Firewall
DMZ2
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Application Server: valutazione
INTERNET
•Prestazioni: elevate grazie al load-balancing dinamico
•Scalabilità: virtualmente illimitata replicando l’application server
•Disponibilità: capacità di fail-over a livello degli oggetti eseguiti all’interno dell’application server, gestione delle transazioni
•Complessità: ambienti generalmente complessi da manutenere
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Architetture software: il pattern MCV
• Come distribuire le funzionalità software tra web server e application server?
• Architettura Model View Contoller (MVC):
client controller model
view
richiede aggiorna
notificapresenta
• Scopo: separare le funzioni in moduli software ben disaccoppiati e rendere le logiche di business (model) riusabili in contesti diversi, sia Web che non
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
MVC su Web (MVC 2)
browserController(servlet)
Model(action classes)
View(Template JSP + custom tag
richiestaHTTP
Pagina HTML
Model(oggetti di business
EJB)
Oggetti di stato(JavaBeans)
DBClient Web server + engine
App. server
Database
• Il controller è configurato per dirigere ogni richiesta alla opportuna action
• La action class invoca gli oggetti di business necessari
• Il controller chiama un template per visualizzare i risultati
• Il template traduce (in HTML) i risultati prodotti dalla action, senza neppure sapere come sono stati costruiti
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Prestazioni delle architetture Web
• Le prestazioni sono uno dei criteri più importanti per la scelta dell’architettura
• Buon esempio delle considerazioni progettuali necessarie durante il progetto di un’applicazione Web
• I requisiti di prestazione sono basati sul numero di utenti:– Semplice da stimare per siti Intranet/Extranet (B2B)– Difficilmente valutabile per siti Web pubblici (B2C)
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Metriche di performance
• N° di richieste di pagine: valore medio e di picco di richieste inviate dai client [pagine/secondo]
• N° di utenti concorrenti: valore medio e di picco di utenti connessi al sito contemporaneamente
• Tempo di risposta: massimo intervallo di tempo di attesa di risposta del server da parte del client [time to first byte (TTFB) e time to last byte (TTLB)]
• Mix di richieste: per applicazioni con pagine complesse, si definisce il mix plausibile di accessi alle differenti pagine da parte dell’utente medio (assegnando una probabilità ad ogni pagina)
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Algoritmo di ottimizzazione
• Idea:rimuovere i colli di bottiglia finché i requisiti non risultano soddisfatti
• Collo di bottiglia: problema che si verifica nel componente più lento del sistema
Definisci unaconfigurazione
Verifica performance
Rimuovi colli dibottiglia (se possib.)
Identificacolli di bottiglia
Requisitisoddisfatti?
Stop
Requisiti diperformance
Start
sì
no
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Ottimizzazione di prestazioni
di applicazioni Web Tre possibilità di intervento:• Ottimizzazione del codice applicativo
– Difficile
• Potenziamento dell’architettura– Costoso
• Web caching: memorizzazione temporanea di risorse in modo da garantire accesso veloce– Basso costo– Basso impatto sull’applicazione– Basse conoscenze tecniche richieste
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Benefici del Web Caching
• Riduzione della latenza di rete: una cache vicina al client consente risposte più veloci perché non è necessario trasmettere informazioni su lunghi tratti di rete – Riduzione di uso della banda e tempo di risposta
• Riduzione dello sforzo computazionale: risorse dinamiche vengono recuperate immediatamente invece che ricalcolate
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Cosa mettere in cache
• Tutto ciò che contribuisce a costruire la risposta del Web Server:– Pagine statiche– Files multimediali – Fammenti di pagine dinamiche computate– Dati intermedi consumati dallo scripting
per computare pagine– Risultati di queries a database o di altre
computazioni
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Cosa mettere in cache
• Tutto ciò che contribuisce a costruire la risposta del Web Server:– Pagine statiche– Files multimediali – Fammenti di pagine dinamiche computate– Dati intermedi consumati dallo scripting
per computare pagine– Risultati di queries a database o di altre
computazioni
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Dove mettere la cache 1:
browser caching
• E’ una directory dell’HD dell’utente• Memorizza pagine e risorse statiche• Annulla la latenza di rete• Non è affidabile in generale, il cliente o il fornitore di
contenuti la può disabilitare
Client(browser)
Cache
Internet
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Dove mettere la cache 2:
proxy caching
• Cache basata su proxy HTTP
• Posizionata tra Intranet e Internet
Client(browser)
Client(browser)
Cache
InternetIntranet
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Dove mettere la cache 3:
Content Delivery Network
• Infrastruttura di cache complessa• Composta da molti nodi anche distribuiti
geograficamente• Gestita da fornitori specializzati
Client(browser)
Client(browser)
Cache 1Cache 3
Cache 2
CDN
° Web server
° Engine
° App. server Database
Internet DMZ Intranet
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Dove mettere la cache 4:server accelerators
• Buffer posizionato di fronte alla macchina che produce risposte dinamiche
• Permette di allocare minor potenza computazionale all’architettura del server
Client(browser)
Client(browser)
Cache° Web server
° Script engine
° Application server Database
Internet DMZ Intranet
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Popolazione della cache: metodo push
CacheCopia
periodicaRichiesta
Risposta dacache
server
PUSH:• La copia in cache avviene con periodicità
fissa, indipendentemente dalle richieste
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Popolazione della cache: metodo pull
PULL:• La copia in cache avviene nel momento in cui una
richiesta del client scatena un avviso di assenza da cache
• Usato più spesso
Cache
Avviso diassenza da
cache
Aggiornamentodella cache
Richiesta
Risposta dacache Server
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Protocolli di gestione della cache
• Protocolli che raccolgono regole per l’aggiornamento della cache:– Expiration rules: definiscono la durata della validità di
un oggetto in cache– Invalidation rules: criteri per stabilire se l’oggetto in
cache non è conforme con l’originale corrente
• Sono molto complessi per risorse dinamiche• E’ possibile inserire delle direttive di caching
nelle risorse dinamiche (per esempio mediante custom tag nelle pagine JSP)
• Proposta di standard: Edge Side Include (ESI) www.esi.org