Thread View: pl.internet.polip
6 messages
6 total messages
Started by Jaroslaw Rafa
Tue, 23 Feb 1999 14:46
Pseudo-cache NASKu
Author: Jaroslaw Rafa
Date: Tue, 23 Feb 1999 14:46
Date: Tue, 23 Feb 1999 14:46
51 lines
2514 bytes
2514 bytes
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.
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...
:-(((
--15:11:03-- http://www.sunpack.com:80/RTF/latest/r2hsparcsol414.tar.gz
=> 'r2hsparcsol414.tar.gz.4'
Connecting to www.sunpack.com:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 342,146 [application/x-tar]
0K -> .......... .......... .......... .......... .......... [ 14%]
50K -> .......... .......... .......... .......... .......... [ 29%]
100K -> .......... .......... .......... .......... .......... [ 44%]
150K -> .......... .......... .......... .......... .......... [ 59%]
200K -> .......... .......... .......... .......... . [ 72%]
15:11:04 (610.62 KB/s) - Connection closed at byte 247608. Retrying.
[... i tak 20 razy ...]
Ani chybi "uszczesliwono" mnie jakims wspanialym cache... Wrrr! Bede gryzl,
jezeli jeszcze raz ktos mi powie cokolwiek o cachowaniu WWW!!!!
A teraz niech ten geniusz ktory to wymyslil mi powie JAK ja mam ten plik
sciagnac?
Przez proxy w ICM-ie nie moge, bo jest "restricted" - nie wiadomo dlaczego,
chociaz jeszcze niedawno mozna bylo z niego korzystac...
ERROR: The requested URL could not be retrieved
While trying to retrieve the URL:
http://www.sunpack.com/RTF/latest/r2hsparcsol414.tar.gz
The following error was encountered:
ERROR 102 -- You cannot access the Web resource requested by this
URL.
This means that:
The system administrator has restricted access to this URL.
Wrrrr!!!! Mam ochote gryzc...
Pozdrowienia,
Jaroslaw Rafa
raj@inf.wsp.krakow.pl
Re: Pseudo-cache NASKu
Author: Marcin Rutkowski
Date: Tue, 23 Feb 1999 15:59
Date: Tue, 23 Feb 1999 15:59
20 lines
1506 bytes
1506 bytes
>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... >:-((( I tak bedzie az Homo Interneticus wymieni modem na "bebenek" albo "ognisko z pokrywka" ;-> P.S. Odnosze wrazenie (pewnie jak zwykle sie myle), ze tymi "bajerami" (proxy, etc.) zajmuja sie teoretycy, ktorym sie wydaje, ze uszczesliwia wszystkich "na sile" !? -- Marcin Rutkowski MAIL: marcinru@vc.pl WWW: http://friko.onet.pl/el/marcinru/
Re: Pseudo-cache NASKu
Author: Wojtek Sylwestrzak
Date: Tue, 23 Feb 1999 16:22
Date: Tue, 23 Feb 1999 16:22
11 lines
1187 bytes
1187 bytes
Marcin Rutkowski wrote: > > P.S. Odnosze wrazenie (pewnie jak zwykle sie myle), ze tymi > "bajerami" (proxy, etc.) zajmuja sie teoretycy, ktorym sie > wydaje, ze uszczesliwia wszystkich "na sile" !? > raczej praktycy, no a z tym 'na sile', to masz troche racji. --w
Re: Pseudo-cache NASKu
Author: Marek Moskal
Date: Tue, 23 Feb 1999 17:25
Date: Tue, 23 Feb 1999 17:25
11 lines
1081 bytes
1081 bytes
Marcin Rutkowski napisal(a) dnia [23/02/99]: >P.S. Odnosze wrazenie (pewnie jak zwykle sie myle), ze tymi >"bajerami" (proxy, etc.) zajmuja sie teoretycy, ktorym sie >wydaje, ze uszczesliwia wszystkich "na sile" !? MBSZ po prostu nie testują w swoich laboratoriach wszystkich możliwości i potem to wychodzi "w praniu" ;( -- (moskit@irc.pl)
Re: Pseudo-cache NASKu
Author: 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
Re: Pseudo-cache NASKu
Author: Michal Szokolo
Date: Thu, 11 Mar 1999 12:57
Date: Thu, 11 Mar 1999 12:57
20 lines
1975 bytes
1975 bytes
Michal Mosiewicz napisał(a):
> 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
Oczywiście zakładając, że dany w3cache nie doklei do urwanego pliku
tekstów typu "my som sorry, plik siem byl urwal", co zalatwia odmownie
dociąganie - dostajesz owszem te swoje xMB ale w środku śmiecie.
--
PMP IT Consulting | PMP takes care of IT. Since 1992.
00-679 Warszawa ul. Wilcza 66/68 |
tel. 844-63-19, 602-688-317, | Visit us at http://www.pmp.com.pl/
602-518-132, 501-199-046 |
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads