Názory k článku Volný nasazuje CProxy

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 ...

Podle me nasazovani podobnych technik u ADSL a jinych broadbandu naprosto postrada smysl a je to akorat zbytecna zatez na server. Ty objemove limity jsou nastavene tak, ze pri normalnim browseni je prakticny nemozne je prekrocit, a tech par usetrenych kilobytu se na rychlosti imho moc neprojevi..
Nepredpokladam, ze by cproxy zvladala online rekomprimaci filmu a mp3 prenasenych p2p klienty :-)).

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...)

Jestli jsem to dobře pochopil, tak si musím stáhnout nějaký program pro Windows, jinak mám prostě smůlu? Tak to není žádné čistě serverové řešení.

Pro mě osobně by teda bylo lepší, kdyby ten proxy běžel někde u poskytovatele a nastavení bych si prováděl přes web(doma nepoužívám windows a ve škole nepoužívám dial-up). A nebo ta PPP komprese, ale to už bych toho chtěl příliš;)

pekne hnusna uvodni reklama !

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.

tak tak. CProxy pouzivam cca rok, a je fakt, ze kazdou chvili musim v Opere vypnout proxy server (nekolikrat za den, nekdy nekolikrat za hodinu. Hlavne vecer). Vecne to nefunguje. Nechci rict, ze je to spatna vec, to v zadnem pripade, ale platit za to teda nebudu. To by to muselo slapat jinak. Jinak jejich podpora je vazne dobra, dotazy se snazi resit co nejdriv a pomoc je kolikrat znat. Zadne odpovedi typu "nam to jede, problem je u Vas".

CProxy umožňuje jak kompresi HTML, tak kompresi obrázků (a to volitelně i v takové kvalitě, že se to celkem ani nepozná, žádné fleky) tak i vypouštění blbostí z HTML. To vše je uživatelsky nastavitelné.
U GPRS může být chyba kdekoliv, u Volnyho by problémy s připojením být neměly, když to hostuje Volny u sebe.

No nevim.
CProxy pouzivam na GPRS ET, ale velmi casto je to nefunkcni a musim to vypinat. Pokud ale jede, tak je to super.

"optimalizace HTML kódu: na serveru prý dochází k odstraňování "zbytečností" (částí HTML kódu, které neovlivňují výsledné zobrazení, jako například komentáře); naopak, a to mne docela překvapilo, nedochází k žádné kompresi přenášeného HTML kódu"

Neni to spise naopak? Cproxy na 100% komprimuje HTML kod. Ze by CProxy odebiralo komentare a zbytecne casti HTML kodu jsem si nevsiml...

to se mi nejak nezda, ze by se snazili extra komprimovat obrazky a nepouzili kompresi html kodu na urovni http, ktera je ve standardu a navic je podporovana vetsinou prohlizecu a misto toho pouzivali zrudnosti typu odebirani komentaru

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).