Vlákno názorů k článku Volný nasazuje CProxy od Dan Lukes - rozhodne mi vsak IMS pripada intuitivnejsie A tak to...

rozhodne mi vsak IMS pripada intuitivnejsie

A tak to jiste, pojem "datum a cas" chape prevazne spravne nepochybne vic lidi nez pojem "hash" nebo "bezvyznamovy identifikator". Ale, rekneme si na rovinu, tohle neni debata pro "bezneho uzivatele WWW" - to je debata pro programatora WWW cache a/nebo browseru. A tem by nemel delat zasadni problem zadny z predestrenych terminu. A jestli si ukladam udaj A1 a porovnavam ho z pozdeji ziskanym udajem A2 na "mensi nez" nebo jestli si ukladam udaj B1 a s pozdeji ziskanym udajem B2 ho porovnavam na nerovnost snad neni az takovy rozdil, aby se na jeho zaklade dala preferovat jedna metoda pred druhou ...

Podotykam, ze ja neobhajuji ETagy za kazdou cenu - cache hodna toho jmena by mela umet spravne pracovat s obojim, protoze to vyzaduje specifikace - obzvlast, kdyz to nejsou dve nejak zvlast rozdilne metody, ale dvakrat tataz metoda (porovnavani ulozeneho s dodanym udajem, jen je pokazde aplikovana na jiny udaj) - takze se ani nelze vymlouvat na nejake implementacni obtize ...

napr. SQUID nepodporuje plne ETag, ako su na tom ine proxace a klienty neviem, rozhodne mi vsak IMS pripada intuitivnejsie...

Vzhledem k tomu, ze IMS lze vzdy implementovat pomoci ETAGu, ale obracene to neplati, tak tu "vetsi vhodnost" IMS tak uplne nevidim - a vy jste zadny duvod nenaznacil. Me by se skoro zdalo, ze lepsi reseni je to univerzalnejsi, ale samozrejme, ze je mozne, ze jsem neco prehledl ...

Ja netvrdim ze IMS je vzdy lahke implementovat. Pokial to vsak je mozne, povazujem za vhodnejsie implementovat IMS ako ETag.

Nakoniec, obe entity su tu za ucelom toho isteho a skutocny problem je v tom, ze koderi sa nenamahaju s jednym ani druhym, a providerom potom neostava nic ine ako komprimovat

Podmineny dotaz jako podmineny dotaz, HIT (304) tim padem delaji oba, stejne minimum dat prenaseji take obe metody. Tak neni jasne, v cem presne spatrujete rozdil respektive vyhodu detekce podle casu ...

Hm, a psal jste nekdy nejake (netrivialni) dynamicke stranky? Zkuste se zamyslet, kolik prace by stalo do nich KOREKTNE implementovat "If-Modified-Since". Nakonec vam jako jedine rozumne vyleze mit nekde ulozene "hashe" stranky pro dany cas zjistovat, jestli je soucasna podoba shodna s tou, kterou dostal klient. Coz je ale ekvivalentni tem ETagum ;-)

ani nie tak ETag a If-None-Match ako skor vyriesit spolahlivo a funkcne If-Modified-Since: pretoze odpoved 304 (ktora nevracia data len informuje ze tie u klienta su stale aktualne) sa tiez rata za HIT, pricom prenasa minimum dat.
Tiez by pomohlo spravne nastavovat Cache-Control: private verzus public a nie len vsade nastavovat no-cache...

Ale o tom by museli koderi dynamickych stranok vediet, ze ano...

cely problem je v tom, ze s tymto provider neurobi nic, zatialco kompresiu nasadi pomerne lahko...

No, a prave tohle vsechno resi jiz zminene ETagy a podminene dotazy jako alternativa k cacheovani na zaklade casu a "nedotazovani se". LOGy mate, protoze na stranku se klient zeptat musi - jen, v pripade, ze se pozna, ze se nezmenila mu poslete "nezmenila" a nikoli celou stranku. Taktez nepotrebujete u stranky predem vedet jak dlouho bude platna. Ani problem s nekonzistenci neexistuje, protoze varianta "pouzila se starsi verze z cache, kdyz existuje novejsi" nepripada v uvahu.

Mimochodem, kdyz se podivam na komunikaci, ktera probiha pri odesilani prave tohoto prispevku, pak lze spatrit (mimo jine):

GET /css/lu_global.css HTTP/1.1
...
Accept-Encoding: gzip,deflate
If-Modified-Since: Wed, 16 Jun 2004 07:16:46 GMT
If-None-Match: "140d8d6-271a-40cff3de"-2
...

Na coz prichazi odpoved:

304 Not Modified
...
Cache-Control: private, max-age=86400
Expires: Mon, 28 Jun 2004 20:11:10 GMT
ETag: "140d8d6-271a-40cff3de"-2
...

Jinymi slovy, shora naznacene reseni neni jen ciste teoretickou konstrukci - ale dokonce se, zrejme, skutecne pouziva. Tedy, pokud se samozrejme spravci chce - a to jeste za predpokladu, ze sve praci rozumi.

www.centrum.cz sice ETAGy pouziva a v pripade podmineneho dotazu reaguje take pouze "not modified". www.seznam.cz ETAGy pouziva take, ale pri kazdem pristupu na stranku je ETAG jiny - takze podminka dotazu je vzdy nesplnena a stranka se vzdy prenasi cela. Nicmene kdyz uz neni seznam ohleduplny takhle, ma alespon implementovano jine reseni - jako jediny z techto tri serveru reaguje na informaci klienta, ze prenasena data lze komprimovat a stranku prenasi skutecne komprimovanou. Takze alespon nejaka uspora ...

Samo ze ne. Je te z nekolika duvodu:

1) Statistiky/logy. Uz jsem vysvetloval v tomto threadu o nekolik prispevku vyse (23.06.2004, 20:31), proc jsou statistiky dulezite.

2) Fakt, ze by se muselo u kazde stranky vymyslet, jak dlouho ji cachovat.

3) Problemy s nekonzistenci. Byl byste na nejake strance a presel na jinou a tam by (treba) "zmizel" ze sloupecku clanku ten nejnovejsi, protoze se natahla starsi verze z cache, kde nebyl. IMHO dost matouci.

V realu proste to cachovani neprinasi tolik, aby se vyse uvedene komplikace vyplatily.

Ale jak jste videl, tak Seznam (i Centrum) u obrazku a dalsich statickych veci (CSS) cachovani pouzivaji.

Je to tak, je potřeba začít jednoduššími příklady.
A teď tedy něco těžšího pro lidi, kteří si o dynamických stránkách přečetli jenom představy Jirky Koska.
Proč na www.seznam.cz není Expires hodnota z Last-Modified + 10 minut?
Nevěřím, že by to tak bylo z pouhé neznalosti!

A vida, toho GMT jsem si nevsiml :-)

Pokus (img.seznam.cz je alias pro 1.im.cz):

$ telnet 1.im.cz 80
GET /szn/img/hp/szn-logo-new.gif HTTP/1.1
Host: 1.im.cz

HTTP/1.0 200 OK
Date: Fri, 25 Jun 2004 07:20:56 GMT
Server: Boa/0.94.13
Connection: close
Content-Length: 4307
Last-Modified: Fri, 30 Apr 2004 09:32:39 GMT
Expires: Fri, 25 Jun 2004 09:20:56 GMT
Cache-Control: max-age=7200
Content-Type: image/gif

Vzhledem k tomu, ze cas je uveden v GMT, ktery je oproti nasemu (CEST) pozadu o 2 hodiny, tak se to jevi, ze pozadovany zdroj expiruje okamzite. Ale on expiruje za 2 hodiny, takze v prikladu az v 11:20 CEST :-).

U dynamickych stranek je to jasne - protoze jsou dynamicke a je zadouci mit hity v logu.

Ted jsem se koukal, a img.seznam.cz opravdu posila Expires nastavene na aktualni cas. Proc to tak maji, netusim, zkuste se jich zeptat :-) Alespon ze u cache control maji max-age=7200.

Tak proč má konkrétně www.seznam.cz v Expires vždy aktuální hodnotu času, tedy totéž, co v Date ?
(Stejně ale většina klientů se řídí Last-Modified a ne ETagy, takže to je jen další výmluva pro neznalé, že jako nikde nic nešvidlují. - No ale když někdo chce na víře vydělávat peníze...)

A ty ETagy Apache podporuje a Seznam a Centrum je pouziva...

To jsme ovsem pozapomeli na "ten spravny" zpusob jak se tyto veci resi - a to je ETag (ze strany serveru), a podmineny (If-None-Match) pozadavek ze strany klienta. Tim si sice neusetrime dotaz samotny, ale prenos odpovedi uz ano - a tato metoda umoznuje resit prave ty situace, kdy ke zmene stranky dochazi nepravidelne. A dokonce ani neprijde to o "hit" v LOGu...

Zalezi na tom, co je to "chybne". Stranky freemailu budu asi chtit cachovat tezko :-)

Treba takovy vypis clanku na zpravodajstvi by se mozna uz cachovat dal. Jenze... Na te strance jsou treba vypisy poslednich zprav. A to je informace, ktera zastarava hodne rychle. Tak bych mohl pokracovat dal. A zjistime, ze vpodstate jedine co se da rozumne cachovat jsou obrazky a CSS. A ty - svete div se - maji vetsinou Expires nastaveno na docela dlouhou dobu.

K tem "pofidernim" hodnocenim a statistikam: Mozna delate svoji praci a nezajima vas jak... Ale produkt manazery portalu vysledky jejich prace zajimaji. A prakticky jedina moznost, jak svoji uspesnost zmerit, maji prave pomoci statistik navstevnosti. Jejich pouzivani pro reklamu je sice nejviditelnejsi, ale ne nejpodstatnejsi.

Je to ještě horší. Někde tam mají snad schválně nastaveno chybné Expires.
Proč, já se dokonce domnívám, že to není z blbosti, ale schválně, neboť si takto zvyšují počet přístupů na server v různých pofiderních hodnoceních a (reklamních) statistikách.

No, ono by uplne stacilo, kdyby slavne "portaly" pouzivaly Content-Encoding: gzip, korektne u vseho nastavovaly Expires: nebo Cachce-Control:, naucily se puzivat CSS, apod. Tim spadne prumerny traffic radove 10x.

Zmensit JPG o par desitek procent je sice hezke, ale vcelku na nic, kdyz se pritom zmeni na barevnej flek.

Kdyby misto techto obskurtnich kravin radsi dial-upovi operatori konecne po desetiletich povolili on-line komprese primo v PPP protokolu (kterou zcela zamerne celou dobu blokuji - klienti se snazi o tom vyjednat, modemove rosty neakceptuji) tak k zadnemu zhorseni kvality dojit nemusi/nemuze a zrovna v pripade HTML je to velmi podstatne zrychleni klidne i 10x...(beze ztraty kvality).