[HWSW]

A Zopfli nevû új tömörítési algoritmussal 3-8 százalékkal nagyobb tömörítési sûrûség érhetõ el, ami nagy sávszélesség-igényû átvitelnél érezhetõ különbséget adhat. Az új eljárás kompatibilis a meglévõ kliensoldali kitömörítõ algoritmusokkal, így szerveroldalon, saját hatáskörben is bevezethetõ.
https://www.hwsw.hu/hirek/49897/google-zopfli-zlib-deflate-http-tomorites.html

[patikaatika]

Mi ennek az értelme, 3-8% az semmi, totál nem értem miért fektetnek ebbe energiát, ráadásul sokkal jobban eroforrás zabáló a betömörítés.

[lacyc3]

Sok kicsi sokra megy, gondolom bizonyos mennyiség felett drágább a sávszélesség mint adott plusz %-nyi CPU idõ.

[Jahno]

Idézet: lacyc3 - Dátum: 2013. 03. 01. 15:35

Sok kicsi sokra megy, gondolom bizonyos mennyiség felett drágább a sávszélesség mint adott plusz %-nyi CPU idõ.

Pfff, a jó ég tudja. Bár most ami árat kaptam íreknél a 100 megás vonalra, azon lehidaltam. 100 megabites kihajtásokat viszont röptében tömörítgetni nem egyszerű mutatvány. De majd elolvasom a cikket is.

[galffy]

@patikaatika: Pusztán elméleti síkon: ha egy gigás mobilneted van, akkor +8% az 80 megabájtot jelent. Az azért nem elhanyagolható. Ha pedig szerveroldalon fizetsz sávszélességért (esetleg sokat), akkor szintén jó spórlás lehet.

[patikaatika]

@Gálffy Csaba:
És ki nem szarja le azt a 80mb-ot ami ráadásul az elméleti plafon a nyereségben? Ehhez szerver oldalon egy erõforrás zabáló encoder-t kell implementálni, kliens oldalon meg egy decodert, én már ott leragadtam hogy képesek emberek 7zip-t használni hogy nyerjnekek 10-20 megabájtot egy több gigás fájlnál, felfohatalan amikor a TB-os hdd-k korát éljük, de hajrá, tudod a túlzott spórolás soha nem vezet jó eredményre ))

[patikaatika]

Érdemes megnéznmi a táblázatot, egy ~cd-nyi anyagon a gzip-hez képest hozott 5 a 7-ziphez képest 2Mb-ot, óriási, fantasztikus, kiszámoljam ez százalákosan mennyi?

[Emvy]

@patikaatika: a netes forgalom 3%-os csokkentese az jelentene, hogy varhato ertekben 3%-al kevesebb infrastrukturat kell kiepiteni.

Kiszamoljam neked, hogy ez hany milliard dollar?

[patikaatika]

@Emvy:
Légy oly kedves. Egyébiránt milyen infrastruktúra építést szeretnél ezzel megspórolni?
Itt max sávszélességbõvítésen lehet valamit spórolni, cserébe mindkét oldalon némi munkát kell végezni ) Ha a logikádat követném akkor az ennél lényegesen jobb hatásfokkal rendelkezõ mozgóképtömörítõ algoritmusok fénysebességel tejednének a világban, de nem ezt látom, gondolkodj el rajta, pedig ott nem 3%-ot lehetne fogni ))

[bontom]

@patikaatika: Ne feledjük, hogy ez a ZIP tömörítés hatásfokát igyekszik maximalizálni. Aki ZIP-be tömörít 7zip-el és nem az LZMA algoritmust használja, az magára vessen. De ha a ZIP-et hasonlítod az LZMA-val, ott nem ritka a 40%-os hatásfok különbség az utóbbi javára. Így 7zip-nek van létjogosultsága, fõleg, hogy van rendes plugin is Total Commander alá, így a használata egyszerû, mint a faék.

De hogy ne csak offtopic legyen: hogy egy szinte bruteforce algoritmust prezentál egy csávó a ZIP tömörítésre, az csak akkor szép, ha a bruteforce-nál sokkal gyorsabban éri el az azonos hatásfokot. Hétköznapi haszna meg biztos van, de nem hinném, hogy gyorsan elterjed majd.

[NancsiBacsi]

@patikaatika: Ha 1x tömörítesz be, és 100000x ki, akkor rögtön megéri. Mivel a kitömörítés ugyanolyan sebességû (vagy gyorsabb, mivel kevesebb "token"bõl áll a tömörített anyag), mint eddig volt.

Ezt elsõsorban arra szánják, hogy statikus dolgok legyenek vele jobban tömörítve, nem pedig röptömörítésre. Van egy portál - mittomén index.hu - legyártanak egy képet png formátumban. Ha ezt több szerver szolgálja ki - mondjuk a képeket is 12 - mivel a szerverek sávszélessége véges, akkor 8% esetén rögtön -1 szerver költség. A tömörítés meg igen, lassabb lesz 30x - na bumm, nem 0.1, hanem 3 sec alatt végez vele. Ez még akkor is elviselhetõ, ha a felhasználónak meg kell várnia, de ha nem kell megvárnia, akkor meg pláne semmit se számít.

[YleGreg]

@patikaatika: Gondold el, hogy hányan töltik le a google fõoldalán a képet naponta. A kliens nem tudja cachelni, mert holnap megint más lesz. A szerver(park) viszont egyszer tömöríti naponta, mert onnantól kezdve a cache-ben van. Ha 5 szászalékkal kevesebbet kell küldeni a napi sokszáz millió elsõ oldalletöltésnél, akkor simán megéri, hogy napi egyszer egy ezred másodperc helyett akár két tized másodpercet is foglalkoznia kellett a tömörítéssel.

Tudom, hogy ez a példa sántít, fõleg mert a szerverpark nem közös cache-t használ, de a lényeg remélem átment, hogy ez a módszer nem a házi barkács dolgokban hoz forradalmi változást, hanem az ipari felhasználásban, ahol ha egy százalék (sávszél) terhelés csökkentés egy milló dollárt hoz a konyhára havonta vagy évente, akkor ez a 3-8 százalék megtakarítás még akkor is kifizeti minden évben a bora-bora -i nyaralásomat, ha a prociban bukok néhány ampert.

Egyébként akik szerint 3-8 százalék semmit nem ér, az szóljon és küldöm a számlaszámomat, ahova elutalhatják a nettó fizetésük 5 százalékát, ha tényleg nem számít! 8-)

[didyman]

Idézet: patikaatika - Dátum: 2013. 03. 01. 16:14

@Emvy:
Légy oly kedves. Egyébiránt milyen infrastruktúra építést szeretnél ezzel megspórolni?
Itt max sávszélességbõvítésen lehet valamit spórolni, cserébe mindkét oldalon némi munkát kell végezni ) Ha a logikádat követném akkor az ennél lényegesen jobb hatásfokkal rendelkezõ mozgóképtömörítõ algoritmusok fénysebességel tejednének a világban, de nem ezt látom, gondolkodj el rajta, pedig ott nem 3%-ot lehetne fogni ))

De kurva okos vagy!

[patikaatika]

@NancsiBacsi:
"mivel a szerverek sávszélessége véges"
Ezt fejtsd ki légyszíves? Mi az hogy véges, mennyire vannak a szerverek sávszélessége a maximum közelében?

[patikaatika]

@didyman:
Nem mondtam hogy az vagyok, te meg fröcsögsz, ha valami szakmai véleményed van akkor írd ide kérlek.

[patikaatika]

@NancsiBacsi:
"Ha ezt több szerver szolgálja ki - mondjuk a képeket is 12 - mivel a szerverek sávszélessége véges, akkor 8% esetén rögtön -1 szerver költség"

hát ez elég leegyszerüsítése a dolgoknak

[patikaatika]

@patikaatika:
Tehát ha jól értem mindenki azonnal befogja vezetni ezt a tömörítést hiszen azonnali költségcsökkentõ tényezõként szerepelne, vagy ha mégsem akkor aki itt sávszélesség ls költségmegtakarítás cunamit vízionál annak mi errõl a véleménye?

['Geri']

az interface végülis egyszerű, dependenciája sincs, bár egy kicsomagolót is rakhattak volna a kódba az egyszerűség kedvéért (én ilyet nem láttam benne hirtelen, bár lehet, hogy van).

[kockulat]

Idézet: 'Geri' - Dátum: 2013. 03. 01. 17:34

az interface végülis egyszerű, dependenciája sincs, bár egy kicsomagolót is rakhattak volna a kódba az egyszerűség kedvéért (én ilyet nem láttam benne hirtelen, bár lehet, hogy van).

Mivel abból nem kellett újat implementálni, ezért gondolom azzal nem is vesződött az úriember.

[NancsiBacsi]

@patikaatika: "Ezt fejtsd ki légyszíves? Mi az hogy véges, mennyire vannak a szerverek sávszélessége a maximum közelében?"
Kb 7-8 éve dolgoztam egy webaudit top10-es magyar cégnek, nekik akkor volt vagy 20 db képszerverük. Ez azt jelenti, hogy halál egyszerû webszerverek, minden ugyanaz a statikus tartalom - kép hegyek - vannak. És semmi mást nem csinálnak, csak adják vissza a http kéréseknek a képeket. Az meg hogy a kérés melyik szerverre fut be, az más lapra tartozik - anno megoldották "kézzel" a terhelés elosztást, persze vannak erre más eszközök is.
Egy gigabites sávszél jóindulattal 100MByte nettóban, ami mondjuk 20 Kbyte-os képeket feltételezve 5000 kép/sec. Ha egy oldalon ebbõl van 25 db, akkor 20 felhasználónyi kép másodpercenként. Ha a felhasználók átlag 2 percenként kattintanak, akkor egy ilyen szerver - egyenletes eloszlás esetén - 2400 párhuzamos felhasználót tud kiszolgálni. Az meg nem túl sok, ettõl nagyobb terhelések voltak már akkoriban is.