Názory k článku Test: akcelerují akcelerátory?

To je lišta pro Internet Explorer, která má zvyšovat zabezpečení a mimo jiné blokovat dialery (poněkud nešťastně rezidentním programem).

Ta lista Seznamu je urcena pro MS-DOS? Respektive, co si mame predstavit pod pojmem "rezidentni program"? Ptam se, protoze nekteri autori na LUPE necti terminologii a tyhle aplikace jsem nemel moznost testovat. Kdyz lezu na Internet pres dial-up, mam FQDN reklamnich serveru nastavene na 127.0.0.1 a na rychlost nacitani stranek si rozhodne nestezuji :-)

K výsledkům testů mám několik výhrad:

1. jak bylo docíleno, že dynamické stránky generovaly pro každý akcelerátor pokaždé stejnou stránku o stejném objemu dat? (myšleno včetně reklam apod.)
2. kam se poděla tabulka naměřených hodnot bez akcelerátoru, aby měl čtenář s čím srovnávat?

Myslím, že bez těchto poměrně podstatných věcí nemá smysl nad výsledky jakkoliv uvažovat, protože jsou nic nevypovídající!

ad 2): hodnoty bez akceleratoru reprezentuje posledni radek v tabulce s nazvem Reference...

Aha, už jsem to pochopil, stejně si ale myslím, že by se mělo testovat pro každého ISP zvlášť "s" a "bez", aby člověk věděl, o kolik došlo k navýšení u daného operátora, čímž se spíš otestuje kvalita akcelerátoru než kvalita linky, protože nevidím důvod, proč by dvakrát dva stejné akcelerátory měly u různých ISP urychlovat jinak :o)

:-) Pod tohle bych se podepsal. Neni to vypovidajici, prave naopak, vysledky jsou velmi zkreslene.

1. korektni by bylo merit pomer casu nacteni s akceleraci a bez ni pomoci stejneho pripojeni (jenze to by se clanek nedal postavit za dve hodiny, ale za den a to je moc prace). Pouzitou metodikou je totiz zanedban vliv rychlosti linky jako takove. Ze se modemy dohodly na 28.800 moc neznamena, je zde podstatny vliv ukonceni volani v te ci one siti.
2. defaultni nastaveni se lisi. Jinak si nedovedu vysvetlit rozdil ve vysledky Seznam-Volny pouzivajici podle autora stejny program.
3. ... naslo by se vic chybicek.

mě hlavně zarazil výběr hardware. Pentium 166 má dost práce s renderováním stránky a čas potřebný pro její načtení bude možná skoro zanedbatelný. Neměl by ten test být provedený spíše na silném HW, který případná dekomprese a režie akcelerátoru nepoznamená?

Pokud chceš testovat čistě a jen akceleraci, pak asi ano :o)

Podle me byl ucel testovat akceleraci vcetne telefonni linky a serveru. Zatimco "cista" cesta je www stranka -> komprese -> dekomprese, "spinava" by mela byt www stranka -> prenos -> server -> komprese -> ISP -> prenos -> dekomprese. Je nesmysl do teto trasy navic zahrnovat HW uzivatele, nebot ten muze uzivatel menit. Zbytek ne.

Nicmene z pohledu opravdoveho prozkoumani problematiky se autor skutecne drzel zpatky, protoze zcela zanedbava prenosovou linku mezi web serverem a poskytovatelem, ktera vysledky silne ovlivni. Proto mel byt misto "reference" v tabulkach uveden aspon cas bez komprese pro kazdeho poskytovatele.

Kde je test Contactel akceleratoru? V seznamu operatoru poskytujicich akcelerator je Contactel uveden, ale v testu nikoliv. Byl nejaky duvod ho vyradit?

Bohuzel ted nemam moznost, jak to u autora overit, ale pokud vim, tak Contactel pouziva pro svuj akcelerator stejne "vnitrnosti" jako jeden z ostatnich poskytovatelu v testu (je to myslim Volny, ale nechci si vymyslet). Jakmile to dozjistim, dam zde vedet.

No, ono je docela jedno, jestli ten ci onen pouziva stejne vnitrnosti nebo ne. Mnohem vic zalezi na nastaveni - akcelerator Contactelu umoznuje provoz s klientem nebo bez nej. Bez klienta (vzdalena proxy) je na poskytovateli, jak jej nastavi, coz samozrejme ovlivni vysledky. Ono koneckoncu zalezi i na tom, jak si uzivatel nastavi klienta (pokud jej pouziva).
Ani o jednom se v clanku nic nerika. Ach jo, proc vychazi tolik povrchnich clanku? Nebo je jenom muj pocit, ze _musi_ vyjit xy clanku a pres to nejede vlak?

Aha, tak uz je to jasnejsi. Prislusny radek tabulky vypadl nekde na trase od zpracovani u autora po zpracovani u nas... Jiz jsem jej do clanku pridal.

Poznamku o enginu akceleratoru Contactelu proto muzete povazovat za irelevantni.

Souhlasim s nazorem, ze by se mely zverejnit pro vsechny ISP hodnoty "s" a "bez". Co treba otestovat akceleratory na ISDN dial-up 64/128 nebo alespon opravdu na 56 nebo hodnote blizici se 56 kbps?

Myslim si, ze rozumnejsi je testovat objem prenesenych dat nez neco nejasneho typu "stranka".
Doporucoval bych zkusit "hole" textove soubory a "hole" jpegy se zmenou kvality. Akceleratory vetsinou funguji tak, ze na jedne strane kompresi data pro prenos a na druhe strane je rozbaluji. Toto ma take svoji reziji, ktera nekdy muze byt vetsi nez zisk z prenosu. Takze take zavisi na kvalite PC a serveru na obou stranach prenosu. Zavisi take na umisteni serveru, jeho zatezi a jeho konektivite. Mi napriklad nektere strany chodi rychleji pres PROXY umistene v Americe nez pokud jdu primo. Mohlo by se zdat, ze je to nemozne, ale je to FAKT.

Celkove odflaknuty test....

1)
Tedy, taky si myslím, že testování mělo probíhat pro každého operátora zvlášť "s" a "bez" a ne to porovnávat jen s jedním připojením.
2)
" Všechny akcelerátory byly ponechány ve výchozím nastavení "
Co takhle taky vyzkoušet více možností krom výchozího nastavení? Zablokovat veškerou reklamu, flash, zvětšit kompresi obrázků a uvést hodnoty v další tabulce? Mělo by to tam být, pokud chcete zjistit, jestli tyto věcičky fungují nebo jsou jen reklamním trikem, jak píšete v úvodu článku. Protože nechat to ve výchozím nastavení nemá skoro smysl...

Ano, byla zvolena špatná metodika měření, a vyvozovat
ze špatného experimentu nějaké závěry je potom dost ošidné.
Z fleku bych mohl navrhnout vylepšení, uložit ty 3 titulní
testovací stránky ve statické formě včetně obrázků na nějaký JEDEN
server (webhosting), aby byly stejné podmínky v různé časy,
kdy bylo prováděno měření přenosu, stejné texty, stejné
obrázky, a ne v každou sekundu *o něco* odlišné obsahy,
když už se experimentátor rozhodl testovat na *běžných*
stránkách. Hlavně, když se měřené veličiny pohybují
plus-mínus žádná-celá-nic, tedy v oblasti chyby měření:)
A ono by to zase o tolik víc času nezabralo při přípravě
článku, že ne? :)

"I ty nejrychlejší modemy mohou pracovat na maximální rychlosti 56 kbit/s ve směru downloadu a 33.6 kbit/s ve směru uploadu." - to platí u standardu V.90, už pěkných pár let ale existuje standard V.92, posunující hranici rychlosti uploadu na 48000 bps, a standard V.44 vylepšující kompresi

Ja akceleratory nepouzivam, protoze rad koukam na puvodni obrazky a ne na zmrseniny. Ale rychlost potrebuji take (jedu pres GPRS), tak jsem hledal a nasel. Kombinace Mozilla Firefox + rozsireni Adblock.

Teprve po nakonfigurovani Adblock-u jsem (s hruzou!) zjistil, kolik procent obsahu je balast, reklamy apod. - proste spina :-) A kolik to zere i CPU! Z prace (P4 1.7GHz) jsem byl zvykly pustit si deset a vice TABu ve Firefoxu. Kdyz jsem to zkusil doma bez Adblocku, byl pocitac okamzite tuhy. Tolik flashu, zbytecnych javascriptu, animovanych obrazku - to proste nemel procesor sanci ustihat a konexe k internetu byla take uplne tuha. Bez reklam a balastu (mate sami moznost si v Adblocku interaktivne urcovat, co se vypne) to jelo vsechno v pohode a i na mnohem slabsim stroji (Pentium 600MHz) si zvladam stahovat a cist stejny pocet stranek naraz jako v praci...

Kde jsou doby, kdy se za strojovy cas platilo? To by dnesni marketaci byly bez vyplaty a s milionovymi dluhy! :-)

Rozhodně souhlas. AdBlock je výborný tím "AdBlock-able elements", kdy člověk kouká, co je tam věcí. Vím, že to není moc košer, ale zablokoval jsem i měřáky (NetDot, Monitor atd.) - čekat na to, až se to načte, se mi opravdu nechtělo, navíc hodně času stojí navázání spojení s jiným serverem.

Přesně - oproti jiným proxy má ohromnou výhodu, že se k němu uživatel dostane přímo z prohlížeče tím, že si klikne pravým tlačítkem na to, co ho štve - a nemusí být administrátor, přihlašovat se někam do jiného systému apod. A ten psychologický efekt! Štve mě to, kliknu pravým a "zabiju" to! To je přesně ono :-))

Ad měřáky: to mám také zakázané. Stejně jako některé otravné javascripty. Občas to strašně zdržovalo nebo se původní stránka nenačetla vůbec kvůli timeoutu na měřácký gif (idot). Navíc když nekoukám na reklamu, tak proč se nechat započítat? :-)) Když se koukám z linksu, tak se taky nepodívám na reklamu ani na počítadlový gif.

Zase když má člověk přístup k serveru na páteři, tak mi kamarád ukázal, že privoxy je velmi účinná zbraň. Ale nahrazuje všechny zakázané objekty průhledným gifem roztaženým na velikost původní reklamy. Pak si můžeš zakázat ten gif Adblockem a povolit ho jenom když se stránka bez reklamy graficky rozsype. Moc pěkné: efektní i efektivní.

Proč by to nebylo košér? Každý uživatel by měl mít přeci právo odmítnout něco, za co nechce platit nebo co ho obtěžuje, tak proč ne měřiče a další zbytečnosti, které jen otravují a zpomalují?

Není to košer, protože především "internetové časopisy a noviny" žijí z reklamy. Čtenáři je zpřístupněn obsah a čtenář za to platí právě shlédnutím reklamy. Tohle normálně funguje u tištěných médií, kdy snad ani nikoho nenapadne chtít v trafice odlehčenou verzi časopisu či novin - verzi bez reklamy. A za tyhle média platíme. A ještě si nosíme domů fůru papíru, o který nestojíme.
V absudním případě by to mohlo dopadnout tak, že internetový časopis s vysokou návštěvností může mít minimální objem zobrazené reklamy. Je otázka, zda by to dokázal přežít a je otázka, jestli je pro návštěvníky takového webu zajímavé, aby zanikl.
Zdarma dnes již není nic. Ani čistý vzduch.

V článku není vůbec uvedeno, jak byla nastavena komprese ma modemové lince. Pokud je totiž zapnutá, a to u analogových modemů standardně bývá (MNP5, V42bis, V.44), pak bezeztrátové akcelerátory prakticky nemají šanci - zastoupí je totiž právě komprese v modemech.

Úplně jiná situace je u linek, na kterých datová komprese neběží - to je případ většiny ISDN dialupů a pevných linek, včetně pronajatých okruhů, ADSL, kabelové televize, WiFi atd.

Právě tam se akcelerátor uplatní nejvíce.

Ufff neni to opacne? Dobre komprimovatelna data "zmrvi" acceleratory a na linkove vrstve uz neni co zkomprimovat, ba co vice, muze dokonce dojit k prodlouzeni prenosu?

Jak opačně? Vždyt to popisujete úplně stejně? Nebo jsem to nepochopil?

Jiný pohled na akcelerátory:
Je podezřelé, že ISP tolik pečují o své dialupisty. Není to třeba tak, že to je vhodná příležitost jak přesvědčit uživatele aby používali proxy (a jejich cache) a nezatěžovali jejich drahé vytížené linky ? Nebo by to mohlo mít jiní důvod (navrhněte).

K testu:
Pro srovnání by akcelerátory měly mít nastaveno stejně zachování/redukci obrázků, jinak je test zavádějící. Měl by se stahovat stejný (dost velký) textový (resp.HTML) soubor, pak něco pakovaného (nepůjde to pomaleji než bez akcelerátoru?) a pak třeba ta reálná stránka (musí být ale už v cache daného providera). A očekávat, že se něco urychlí o více než pár procent je naprostý nesmysl.

Skutecne mate dojem, ze ISP pecuji o dial-upisty? :-)

No právě je mi podezřelý, že ISP zveřejňují akcelerátory, musí k tomu dávat support a to vše jen pro blaho zákazníka na dialupu zadarmo - to je zjevná blbost. Tak jak je to tedy? Mě napadlo jen to s využitím jejich cache a šetření linek do netu, ale to by transparentní proxy řešila taky...
Lepší nápad?

A co takhle konkurencni boj ISP? Dialupu porad ubyva, operatori maji volny modemy a snazej se je vyuzit. Jedinej zpusob jak to udelat, je pretahnout uzivatele od konkurence. Volny byl v tomhle prvni a ostatnim ISP asi zacali jeste vic ubyvat uzivatele, tak to museli zavest taky.

Prece jenom tech 100.000 "broadbandistu" musi na tech "modemovych kombajnech" a "pristupovych svazcich" chybet.

Rozhodne nemam dojem, ze by ta technologie byla tak narocna na podporu :-)

Chyba lavky, spravny duvod proc se je snazi ziskat "famou" o nejakych akceleratorech je, ze dostavaji provizi z kazde provolane minuty co skonci u nich!! A ta je celkem dost velka u velkych ISP to muzou byt miliony mesicne.
Tak proto.

Celkem zbytecny kdyz mame tri uz dlouho existujici moznosti jak na dialupu komprimovat:

-na urovni linkove vrsty - modem - MNP 5
-na urovni PPP spojeni je take komprese mozna
-na aplikacni urovni. v HTTP protokolu lze pouzivat i Gzip kompresi. Necekam ze to bude mit kazdy webserver tak bych to resil nejakou proxy na strane ISP. Hodi se pro jine pripojeni nez dialup.

O5 neschopnost ISP...

Omyl! Skutecnej akcelerator neni jen o kompresi, ale i o optimalizaci TCP/IP spojeni. Vetsinou je po celou dobu komunikace navazano jen jedno spojeni, cimz se redukuje pocet SYNC, ACK, ... GZIP je dobrej, ale podporuje ho jen mizive % serveru a komprese modemu zase neni ucinna. Jeji vliv se projevuje pouze v pripadech, ze se stahuje jen nejaky dlouhy dobre komprimovatelny soubor, nevyhodi reklamy,...

Akcelerator je vylepsena verze "tveho" navrhovaneho reseni s proxy u ISP, ale stejne to povazujes za neschopnost ISP ;-))



Jinak ten test je uplne na prd, defaultni nastaveni maji vsechny akceleratory uplne jiny a tak se porovnavaji hrusky s jabkama. Napr. Atlas, Contactel a Idnes maji sice defaulni uroven komprese nastavenou na 50%, ale ve skutecnosti je to mnohem vice(obrazky vypadaji hur) nez u Volnyho a Seznamu pri zachovani 50% urovne komprese.

Celkem me pobavil zpusob provadeni testu, kdy se meri cas potrebny pro nacteni stranky az do okamziku, kdy se v IE objevi "hotovo". Pokud nechate nastaveno v akceleratorech ignorovani reklamy (coz je default), tak to nekdy vypada, ze se stranka nenacte. Tohle je ale vlastnost IE, ktery v pripade nenacteni flashe stranku porad nacita ikdyz je uz nactena a nikdy se IE neobjevi "hotovo".

"GZIP je dobrej, ale podporuje ho jen mizive % serveru"

Hmm, ze by Apache byl tak mizive zastoupen ? Staci povolit jedinou volbu v configu.

podporuje = komprimuje. Pokud GZIP neni na serveru zapnutej(naprosta vetsina serveru), tak je uzivateli uplne jedno, ze to umoznuje. Kdyz na to prijde, tak se to da rozchodit i na IIS.

U Apache 1.3 (a ten je ještě pořád častější) není mod_gzip součástí standardní instalace.

A co to takhle nazvat tunel s online kompresi kombinovany s mrvenim obrazku? A co to takhle realizovat pres neco univerzalnejsiho? Treba OpenVPN a zapnout LZW kompresi? A co takhle prioritizovat kratky SYN/ACK primo na pocitaci? To cely by slo udelat nakym install wizardem. Ciste,systemove,transparentni.
Nespis nechapu marketigovou mluvu...

Prominte, ale vysledky mereni v toho clanku nevypovidaji podle meho nazoru skutecne o nicem, mozna tak o soucasne kvalite telefonni linky a aktualnim mnozstvi reklamy na serverech...

Mozna, ze by pomohla alespon jednoducha vec - ulozit nekam na 1 server nedynamicke stranky, jak navrhoval jiz nekdo vyse a navic provest mereni napr. 20x pro kazdeho ISP a kazdou stranku. Nad takovym merenim jiz by se dala udelat statistika, ktera by o mnohem vypovidala! Napriklad o tom, nakolik je toto mereni skutecne nahodne...

s pozdravem

David Smahel

Rozhodně, snad ve všech metodikách měření je uvedeno, že jedno měření nestačí a že nemá prakticky žádnou váhu, neboť bývá velmi zkresleno; jenže to by výroba článku zabrala moc času, že? a práce smrdí :o)))

Take v testu nebylo uvedeno, jak je to s transparentnostni.
Akcelerator od Atlasu nevyzaduje na strane klienta vubec nic.
Coz je perfektni v pripade pouziti Linuxu, ci jineho operacniho systemu, nebo prohlizece. Nevim, jak je to u ostatnich.

Nechce se mi to celé číst. Zrychluje to, nebo ne? O kolik?

Čekal bych tu informaci na začátku nebo na konci článku, mám ale asi smůlu.

Zrychluje, ale v tomhle článku to neuvidíš...

Jsem pohoršen nad výsledky testu, které pan Bednář provedl a to z následujících důvodů:

1-měření proběhlo v defaultním nastavení jednotlivých akcelerátorů, což je nevypovídající z několika důvodů. Např. Volný, Seznam má 16 možností nastavení a default má nastaven na prostředek, zatím co Atlas, Contactel má nastaven default někam jinam - jen tři možnosti nastavení komprese - velmi skokové (pokud se bavíme o obrázcích). Zmíníme-li nastavení reklamních serverů a nezobrazování flash aplikací tak Volný má v defaultu jen nějaké reklamní formáty a Seznam všechny a jak je to u Atlasu, Contactelu a Tiscali pane redaktore?

Objektivní měření by bylo pouze při maximální kompresi dat.

2-pozastavuji se nad tím, jak jste zmiňoval, že všechny akcelerátory mají graf a "tabulku" obojí vypovídající o přenesených a uspořených datech. Zabýval jste se vůbec tím jestli tyto informace, které jsou zobrazovány uživateli, jsou pravdivé? Já ano a mohu Vás ujistit, že ne. Skutečně vypovídající data jsou pouze u Seznamu a Volný.

Jistě mi dáte za pravdu, že když nastavíte modem na 28.800 bit/s není takovéto měření objektivní.

Jak dosáhnout objektivního měření při srovnání jednotlivých akcelerátorů? Jednoduše.

Stáhnu si požadované www stránky, které chci měřit a vytvořím z nich statické, upozorňuji statické a ne dynamické www stránky, které umístním na jakýkoliv server. Tyto stránky pak měřím. Jen tak lze dosáhnout stejné podmínky pro všechny akcelerátory. Pokud by jste měření chtěl realizovat tak jak jste měřil Vy, musel by jste měřit jednotlivé akcelerátory současně a na linkách se stejnými vlastnostmi, jakých lze dosáhnout pouze umělým "přiškrcením" linky. To vše je trošku technicky náročné.

V čem se akcelerátory odlišují:
Akcelerátory se odlišují nejen v kompresním poměru, ale za zmínku stojí i součtová doba samotné komprese na serveru a doby přenosu k uživateli. Pokud by jste měřil správně tak zjistíte následující:

Kompresní poměr: první-Tiscali (nejvíce komprimoval), druhý- Volný, Seznam, třetí-Contactel, Atlas
Rychlost přenosu: první- Volný, Seznam (nejrychleji přenášel), druhý-Contactel, Atlas, třetí-Tiscali
Při zhodnocení obou parametrů: první- Volný, Seznam, druhý-Contactel, Atlas, třetí-Tiscali.

Uvedení jednotlivých akcelerátorů na trh s určením dodavatelů:
První-Volný (CProxy), druhý-Tiscali (AcceleNet-Kapsch), třetí-Atlas (Artex s.r.o.), čtvrtý-Contactel (Artex s.r.o.), pátý-Seznam (CPoxy).

Objektivita je také závislá na délce měření (metodice), to znamená dlouhodobý průměr z náhodných časů a pokud možno, tak v poměrovém měření .
Vše závisí také na vytížení serverů u příslušného ISP v souvislosti s počtem uživatelů ve špičkách a mimo špičku. Dá se konstatovat, že čím dříve nasazený akcelerátor tím více uživatelů. Ale to je konec konců v zájmu ISP mít dostatečně dimenzované servery.

Závěrem: Autorovi příště doporučuji zabývat se danou problematikou podrobněji a zodpovědněji a pokud nechce nebo nemůže provést objektivní měření, měl by alespoň správně svoje měření okomentovat. Jinak se domnívám, že tím poškozuje nejen sebe, ale i, v tomto případě, operátory a zároveň uživatele ve kterém vzbuzuje nejistotu k danému produktu.

no ne, LUPA zase ukazala, ze pod libivim cepeckem navozujici dojem, ze se jedna o odborny server, skryva jen odporny lamersky bulvarni platek. Autor jen dokazuje, ze dane oblasti absolutne nerozumi, nektere vyrazy jsou opravdu k placi a jsem prekvapeny, ze ten clanek se vubec zverejnil - pseudoodborny server lupa bud nepouziva metodiku schvalovani nebo clanek koriguji stejne lamy jako je autor.