Newsgroup: it.lavoro.professioni.webmaster
Titolo: Tempi di latenza delle richieste HTTP

Buondì,
qualcuno mi sa indicare da cosa dipendono (dettagliatamente) i tempi di 
latenza di una richiesta HTTP e se è possibile misurarli in qualche modo?
Tutto ciò per capire quanto sia utile spingersi in là (ok, lo so il più 
possibile) per ridurre il numero di richieste HTTP necessarie per il 
caricamento di una pagina, piuttosto che cercare altre strade per 
incrementare le performances.
In dettaglio: impostare una data di scadenza bella in là per gli header 
dei vari oggetti mi elimina una marea di richieste, ma ovviamente 
introduce il 'fastidio' di dover rinominare i files in caso di modifica 
e ovviamente vale solo per gli oggetti in cache.
Il nodo cruciale quindi è: come capire se vale la pena di impiegare un 
sacco di tempo per ridurre il numero di richieste (a questo punto per la 
maggior parte immagini di layout e quindi buttarsi (idea terrificante) 
sulle sprite images o sliding doors)?
-- 
-------------------------------------------
Paolo De Dionigi
www.atfriends.net
Responsabile Tecnico Zen Cart Italia

 e ovviamente vale solo per gli oggetti in cache.
Il client non dovrebbe controllare la data di ultima modifica?
La scadenza è una data oltre la quale l'oggetto in cache viene comunque 
richiesto di nuovo alla sorgente, ma comunque un oggetto modificato 
prima della scadenza verrà ritrasferito.

 prima della scadenza verrà ritrasferito.
Non funziona così il caching.
Se specifichi, ad esempio ed usando pseudo sintassi, max-age: 1 mese,
il browser per tutto il mese successivo non richiederà più il file, se lo 
ha in cache.
Questo ha il vantaggio di ridurre enormemente la latenza.
Manlio Perillo

 [...]
Manlio Perillo

 ha in cache.
Cache privata. 
Mi sembra di ricordare che agli oggetti cache server in ns era possibile 
inviare messaggi di aggiornamento per un file dal server principale e 
questi provvedevano a rinfrescare il file indicato.

 Manlio Perillo


 
Per le immagini puoi usare sotto domini multipli:
img1.domain.com
, 
img2.domain.com
, ..., 
imgn.domain.com
Puoi partizionare le immagini a mano, oppure automatizzare la cosa.
Come spiegato nella guida di Yahoo, aumentare troppo il numero di domini 
può causare problemi di latenza nella risoluzione dei nomi.
Manlio Perillo

 Cosa intendi?
Io, banalmente, accodo tramite PHP, in modo automatico, il timestamp 
dell'immagine sul server. Mi viene qualcosa tipo
<img src="img/immagine.jpg?1234567" />
In questo modo il nome dell'immagine nella cache del browser cambia da 
solo quando cambia l'immagine.
La stessa cosa la puoi fare coi css e i js.
Usare gli sprite, comunque, oltre alla latenza migliora le prestazioni per 
due motivi: 
- consente al programma di grafica di comprimere meglio le immagini (gif e 
png, per esempio), perche` ha meno header e piu` dati su cui lavorare.
- sfrutta meglio il window scaling del TCP, aumentando la velocita` 
durante lo scaricamento anche rispetto agli stessi dati sulla medesima 
pipe.
Inoltre presumo migliori anche l'utilizzo della memoria da parte del 
browser, ma qui non sono molto sicuro.
Attenzione comunque ad usare piu` server (
img1.sito.net
, 
img2.sito.net
, ...) perche` e` vero che i browser aprono "solo" due 
connessioni per server, ma e` vero anche che ne aprono al massimo 8 in 
totale (di default), quindi non ha senso andare oltre i 4 domini.
Bye.

Manlio Perillo ha scritto:

Uhm... discretamente complesso (soprattutto da integrare in sistemi open 
già esistenti, senza essere troppo invasivi).
Per ciò che pensi di implementare hai valutato l'impatto in termini di 
carico della cpu vs guadagno ottenuto?
E l'hash map comunque dovrebbe avere a sua volta un aggiornamento pseudo 
continuo, o no?
Visto che conosci la guida di Yahoo, presumo che utilizzi anche tu YSlow 
, per caso sai per quale motivo nel tab performances alla voce sul 
numero di richieste HTTP non vengono conteggiate (a differenza del tab 
stats) le immagini? E' solo una questione relativa al fatto che per 
mantenere la pagina così come è ti fa vedere solo i files su cui puoi 
intervenire?


 [...]
Manlio Perillo

 Ad esempio Nginx permette un riavvio "a caldo".
Ehm... non mi pare molto funzionale in generale. Improponibile in 
ambienti condivisi e comunque ove vi siano 'modifiche' da parte di 
numerosi utenti, no?
[...]


 Bye.
Thanks


 E per le immagini ad esempio di background via css?
Faccio lo stesso, ma di solito solo con css inline.
Se usi questo sistema nei css esterni devi rendere dinamici anche quelli.
 
Bye.

farlo in automatico, vero?
Invece di "<img src='qualcosa' />", metti un tag del tipo
	<?= img_src("qualcosa"); ?>
e definisci una funzione img_src() che legge "qualcosa", guarda il
timestamp e butta fuori l'URL appropriato.
Il problema qui, e' che parecchie cache non cachano affatto niente
che abbia ?, non stanno a guardare se dopo l'ID e' uguale o no. In
quel caso ti tocca mandare roba tipo img/1234567/immagine.jpg, con
un apposito url_rewrite (che basta che elimini il timestamp).
Leonardo
-- 
Enough, enough!  But stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

 [...]
Manlio Perillo

 [...]
Manlio Perillo

 ambiente condisivo...
Si giustissimo, ma daltronde esiste anche l'esigenza opposta, ovvero 
ottimizzare quanto più possibile proprio nell'ottica di ridurre il 
carico del server (e migliorare le performances lato utente) per quei 
casi in cui non si possa avvalersi di soluzioni personalizzate.


Paolo De Dionigi ha scritto:
CUT
rispondo sia a Leonardo sia a Manlio, grazie per le dritte, quella di 
Manlio in effetti l'avevo già letta da qualche parte ma mai approfondita.
Però, c'è un però: esistono studi pubblici sull'impatto di queste 
tecniche? Cioè, non vorrei che per guadagnare sui tempi di latenza si 
andasse poi a perdere in termini di carico della cpu o di tempi di 
rendering, inficiando se non addirittura peggiorando quanto guadagnato 
riducendo il numero di richieste HTTP.


 casi in cui non si possa avvalersi di soluzioni personalizzate.
Tanto per fare un esempio, unbit offre una soluzione per application 
server, e tra queste è presente Nginx + mod_wsgi (da me sviluppato).
Hai un accesso via SSH, via web e via XMLRPC.
Quindi non c'è nessun problema a riavviare il server quando vuoi.
Manlio Perillo