Newsgroup: it.lavoro.professioni.webmaster
Titolo: [dev] servire una risorsa HTTP in "pezzi"

Saluti ed auguri di buon anno.
Mi sto documentando su i modi più efficienti possibili per servire una 
richiesta HTTP, assumendo che una risorsa possa essere suddivisa in 
blocchi logici.
La prima soluzione che mi viene in mente sono i frames.
La soluzione è teoricamente buona, perchè ogni frame è direttamente 
accessibile dal browser, che quindi può mettere in cache le singole parti.
Purtroppo il frames hanno problemi di accessibilità: per gli iframes la 
situazione è la stessa o va un pò meglio?
La seconda soluzione è usare SSI:
http://blog.kovyrin.net/2007/08/05/using-nginx-ssi-and-memcache-to-make-
your-web-applications-faster/
Il problema è che si perdono informazioni importanti per il caching come 
l'header Last-Modified.
In teoria si potrebbe inserire l'header Last-Modified nel trailer della 
risposta HTTP, ma quanti browser supportano una cosa del genere?
Ci sono altre soluzioni?
HTTP5 prevede un nuovo modello per i frames?
Ci sono speranze per XFrame?
Grazie  Manlio Perillo

blocchi logici.
Dipende da che tipo di risorsa e'.
Se il problema e' il NUMERO di richieste, allora ti conviene molto, ma
molto di piu' un sistema di round-robin (e il failover e' free!).
Se invece il problema e' che hai file enormi - penso che non possa che
trattarsi di immagini (non ci credo, che devi servire un HTML di varie
centinaia di Kb; nel caso, hai gia' provato con gzip-encoding?).
Potrebbe rugarti il dover *creare* le richieste - che so: una news box
di 80 Kb che pero' e' sempre la stessa per tutto il giorno, ed inclusa
in una pagina di 2 Kb che e' variabile. In quel caso mi rassegnerei, o
penserei a caricare i pezzi inclusi a colpi di Javascript.
Se e' il tempo di creazione il problema, fai caching locale sul server
- in PHP basta aggiungere un 'require()' in cima e uno in fondo a ogni
pagina da "trattare" in questo modo.
Restano giusto le immagini, spezzettabili.
A quel punto ti conviene di piu' usare tabelle o CSS.
Senza sapere ne' OS, ne' server, ne' linguaggio di generazione pagine,
dare suggerimenti precisi non e' cosi' facile.
Leonardo
-- 
While ordinarily valid that being widespread does not make a statement
true, I feel that the diffusion of anti-evolutionary beliefs does pose
a strong argument for Darwin having been, indeed, sorely mistaken.

 Leonardo
Saluti e grazie   Manlio Perillo

 
http://en.wikipedia.org/wiki/Edge_Side_Includes
Sembra quello che cercavo.
Grazie  Manlio Perillo

l'utente potrebbe averlo disabilitato.
Nel 2008 è un problema irrilevante.
-- 
ciao,
Marco

l'utente potrebbe averlo disabilitato.
Ormai quasi tutti lo hanno disabilitato solo sui siti sconosciuti usando
NoScript o simili. Io sono abituato a vedere "Non hai Javascript!", e ad
attivarlo su richiesta.


 [...]
Faccio un esempio.
Supponiamo di avere un pagina composta da 3 pezzi, A, B, C
- A è il template principale (header, footer, etc); risiede su disco
  e quindi ha una ben definita data di ultima modifica, etc.
  Il lifetime è di circa 1 mese.
- B è un articolo che si trova nel database.
  Nel database è memorizzata la data di ultima modifica; inoltre
  supponiamo che il corpo dell'articolo debba essere formattato in
  HTML.
  Il lifetime è di circa 6 mesi.
- C è, ad esempio, un calendario che visualizza per ogni giorno del mese
  gli appuntamenti personali.
  Il calendario richiede tempo per essere generato, e non ha un lifetime
  ben definito; invece la cache deve essere invalidata "a mano" ad ogni
  modifica.
  Il lifetime è di circa 6 ore.
I 3 pezzi li posso gestire tramite SSI, e programmare "a mano" la cache.
Quello che mi chiedevo era se ci fossero soluzioni che permettano di 
ottimizzare il caching HTTP.
Ossia, non solo ottimizare la generazione delle varie parti lato server, 
ma ottimizzare il caching del client, che dovrebbe richiedere il 
contenuto completo della pagina il meno possibile.
Questo perchè, IMHO, le ottimizazioni più efficaci sono quella sul 
consumo di banda.
Di solito quello che vedo è del caching gestito tutto lato server, sulla 
pagina intera; questi sistemi di caching, poi, gestiscono i vari header 
Cache-Control, Last-Modified, Expires, etc, ma di solito hanno poco a che 
fare con la rappresentazione "reale" dell'entità.
Saluti  Manlio Perillo

consumo di banda.
Considera che spesso la compressione fa miracoli - e anche dare una
ripulita al codice HTML :-)


 Leonardo
Manlio Perillo

javascript, etc).
Brrrrrr... nel senso che se QUELLO ti fa, vuol dire che hai un SACCO o di
immagini o di Javascript, e a quel punto la pagina diventa una bodda come
che la giri. Per ogni 5 byte che risparmi hai come minimo una GET da fare
al server... oddio: son sempre 5 byte risparmiati a costo zero. Dico solo
che in quel caso e' un po' un portare carbone a Newcastle.
