Article View: pl.internet.polip
Article #485Re: Pseudo-cache NASKu
From: Michal Mosiewicz
Date: Wed, 24 Feb 1999 02:29
Date: Wed, 24 Feb 1999 02:29
47 lines
3606 bytes
3606 bytes
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
Technical Details
Message-ID:
<36D36416.1A19B708@interdata.com.pl>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!agh.edu.pl!news.wnaft.agh.edu.pl!news.memax.krakow.pl!paa.gov.pl!news.swierk.pl!uw.edu.pl!news.nask.pl!orion.cst.tpsa.pl!news.task.gda.pl!mimo.lodz.pdi.net!not-for-mailReferences:
<199902231431.PAA05798@ultra.wsp.krakow.pl>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!agh.edu.pl!news.wnaft.agh.edu.pl!news.memax.krakow.pl!paa.gov.pl!news.swierk.pl!uw.edu.pl!news.nask.pl!orion.cst.tpsa.pl!news.task.gda.pl!mimo.lodz.pdi.net!not-for-mail From: Michal Mosiewicz <mimo@interdata.com.pl> Newsgroups: pl.internet.polip Subject: Re: Pseudo-cache NASKu Date: Wed, 24 Feb 1999 03:29:42 +0100 Organization: Interdata s.c., http://www.interdata.com.pl Lines: 47 Message-ID: <36D36416.1A19B708@interdata.com.pl> References: <199902231431.PAA05798@ultra.wsp.krakow.pl> NNTP-Posting-Host: mimo.lodz.pdi.net Mime-Version: 1.0 X-Trace: korweta.task.gda.pl 919824043 10002 195.116.162.218 (24 Feb 1999 02:40:43 GMT) X-Complaints-To: abuse@task.gda.pl NNTP-Posting-Date: 24 Feb 1999 02:40:43 GMT X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.1 i586) X-Accept-Language: pl,en-US,en Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit