Re: Pseudo-cache NASKu

Autor: Michal Mosiewicz (mimo_at_interdata.com.pl)
Data: Wed 24 Feb 1999 - 03:29:42 MET


Jaroslaw Rafa wrote:
>
> Ostatnio tu duzo dyskutowano o rzekomych korzysciach plynacych z
> cache'owania WWW. Zdaje mi sie, ze wlasnie doswiadczylem "dobrodziejstwa" tego
> pseudo-transparentnego cache NASK-u, o ktorym tu ostatnio byla mowa.

Mam wrażenie, że się czepiasz :-) Znaczy czepiasz się cacheów, a nie
tego, że NASK świadczy usługi kiepskiej jakości. To tak jak ja bym
zwalał na routery to, że TPSA serwuje mi w porywach 150 B/s z zagranicy
i mówił o rzekomych korzyściach korzystania z routerów.

> Probowalem sobie sciagnac konwerter RTFtoHTML. Szlo sobie spokojnie ok. 3
> KB/s, ale nagle sie urwalo. I oto co sie dzieje przy nastepnych probach
> sciagania? Transfer ok. 600 KB/s (dziwne, nie? ;-)), ale plik urywa sie
> raptownie dokladnie w tym samym miejscu! I za nic nie da sie go sciagnac...
> :-(((

Po pierwsze - jak chcesz wymusić sobie świeży zasób, i wiesz że po
drugiej stronie jest statyczna strona, to istnieje najbanalniejszy
sposób na świecie dodajesz na końcu URL-a "?cos".

Po drugie - nie ma pewności, że to cache nasku, a nie inny cache. Jakbyś
wywołał wget'a z -Yoff, to wtedy byśmy mogli to wykluczyć, a na razie
nie wiemy i można przyjąć, że admin tak ustawił wgeta globalnie, że
korzysta z _jakiegoś_ cache'a, a nie koniecznie tego naskowego. Po
trzecie- dodajesz: --header "Cache-control: no-cache" i wiesz, że
normalne cache są już nie straszne, chyba że jakieś chore, co nie
reagują na cache-control (możesz też użyć "IMS-a" lub "Etag-a"). Po
piąte - jeśli cache działa prawidłowo i dałeś retries albo -c w wgecie,
to ten powinien próbować kontynuować transfer od przerwanego miejsca. U
ciebie pojawi się nagłówek o zakresie bajtów do pobrania. Jeśli cache
jest dobry, to stwierdzi, że danego fragmentu pliku u siebie nie ma i
pośle request dalej. Serwer po drugiej stronie może się określić, czy
umie podać ten fragment i go ewentualnie dośle, albo puści cały plik
jeszcze raz, jeśli nie zna "Accept-ranges". Tak czy inaczej - w dobrym
cacheu to spowoduje dociągnięcie lub ponowienie ciągnięcia. Po szóste -
nie jest wykluczone, że cache zadziałał prawidłowo, a Ty niesłusznie go
winisz. Mogło się zdarzyć, że on próbował wysłać zlecenie dalej, ale
sieć była niedostępna - wtedy transfer się urywał. Jakbyś puścił
nagłówki od transmisji, to można powiedzieć, co działa źle, ale w
powyższym było za mało informacji.

Michał

-- 
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 2148340
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:19:42 MET DST