Autor: Michał Mosiewicz (mimo_at_lodz.pdi.net)
Data: Mon 27 Oct 1997 - 16:32:34 MET
Robert Maron wrote:
>
> Michał: [pl.listserv.polip: Mon, 27 Oct 1997 00:37:22 +0100]
> : Wolałbyś, żeby cache sprawdzały za każdym razem last-modified przy
> : każdym requeście? Takie sprawdzenie, to transfer średnio 200-300 bajtów.
> : Ta strona ma wielkość przeciętnie 10-20kB. W momencie, gdy liczba
> : odwołań do tej strony przekroczy 10/minutę, to tylko sprawę pogarszasz.
> : A przecież zależy nam, żeby w3cache działały lepiej przy wyższym ruchu,
> : prawda?
>
> tu akurat cos Ci sie powladkowalo; jesli strona sie nie zmienila, wiec
> zamiast strony ciagniesz tylko l-m no to _zawsze_ zyskujesz; no nie?
> nawet, gdyby l-m bylo ciagniete przy kazdym dostepie (bez sensu oczywiscie)
Policz sobie ile tutaj poszło bajtów:
GET http://www.microsoft.com/ HTTP/1.1
Host: www.microsoft.com
If-Modified-Since: Mon, 27 Oct 1997 14:11:15 GMT
User-Agent: some-user-agent
Dolicz do tego jeszcze informacje jakie dołoży proxy. Dolicz to, co
jeszcze wysyła klient. Zawiń to wszystko w pakiety i okaże się, że
trochę tego poleci. Natomiast, gdy masz expires'a w przyszłości, to w
ogóle możesz uniknąć wysyłania IMS GET, bo wiesz, że zasób jest
aktualny. I dzięki temu czas odpowiedzi robi się krótszy.
Na marginesie, muszę teraz trochę przed Wojtkiem odszczekać... Wczoraj
jak sprawdzałem, serwowali expiresy na 5 minut do przodu - dzisiaj już
są sekundę do tyłu + cache-control-private, więc tym razem przyznaję, że
ta strona nie będzie już w ogóle cache'owana. Chodzi mi jednak o samą
ideę stosowania przyszlościowych expiresów jako metody na *obniżanie*
ruchu.
Michał
-- ******** MEMBER OF THE INTERNATIONAL PROGRAMMERS GUILD ******** WWW: http://www.lodz.pdi.net/~mimo tel: Int. Acc. Code + 48 42 148340 add: Michal Mosiewicz * Bugaj 66 m.54 * 95-200 Pabianice * POLAND
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 16:06:33 MET DST