zkusenosti s pouzivanim delta updatu

10.2.2007 20:47 | Přečteno: 993× | Obecne linux

Mam hodne spatne pripojeni k internetu, tak jsem se rozhodl pouzivat delta rozdily v zdrojacich, abych zrychlil stahovani, ktere nejvice brzdi update meho gentoo. A tady jsou zkusenosti po mesici kazdodenniho updatovani.

Nejdrive pro ty co neznaji deltaupdaty, tak je to celkem dobre popsano ve tretim dily serialu gentoo a GPRS na rootu. Updatovani portage stromu je opravdu vyrazne sviznejsi nez pri pouziti klasickeho emerge --sync, sice je aktualizovan pouze jednou za den, ale stejne asi vetsina neaktualizuje casteji. Naopak pri nizsi frekvenci updatu je potreba stahnou vsechny rozdily mezi dny, coz pri mene caste aktualizaci nez je jednou za tyden se uz nevyplati. Take je potreba stahnout uvodni portage snapshot, ktery ma cca 30MB, coz je lepsi na pocitaci s rychlejsim pripojeni a potom ho jen prenest. Updatovani portage stromu pomoci rozdilu a jednotlivych baliku je nezavisle, takze se daji pouzivat i jednotlive.

A ted to hlavni co by melo usetrit nejvice casu, rozdily ve zdrojacich. Taky je par nepeknych problemu. Prvni je ze nejsou podporovany zip archivy, takze kdyz napriklad chci pomoci rozdilu stahnout nexuiz (200MB), tak nemuzu a musel bych stahovat cely. Druhou je, ze obcas je u nektereho baliku deltaup-queue, coz po deseti pokusech vede ke stazeni celeho baliku. Pokud se, ale povede stahnout balik, je vyhrano. Uspora je velmi vyrazna, vetsinou pres 95%.

Celkove hodnotim toto jako dobry napad na usporu prenosu a kdyby se aspon dodelali zip archivy, bylo by to velmi dobre. Pri kazdodennim updatovani je stahovani rozdilu ve stromu velmi dobre, u baliku jen obcas, ale stejne se dosahuje uspory kolem 75% prenosu. Tudiz myslim jasna volba pro ty co maji aspon prumerny pocitac (kvuli rekonstrukci baliku) a pomale pripojeni (pripadne chteji mit male prenosu kvuli FUP). Pokud vas to zaujalo a mate nejake otazky, tak odpovim v diskuzi.

       

Komentáře

[Käyttäjä 11133]

Kdyby se nepoužívali binární diffy (na archivy), ale normální diffy (na zdrojové kódy) mezi verzemi tak by to IMO ušetřilo ještě víc.

[Radek Podgorny]

Mam pocit, ze neco takoveho se prave dela. Proto to nefunguje na archivy...

[Käyttäjä 11133]

Nedělá, dělá to binární diffy na ty tar.bz2, tar.gz,.. archivy.

[AloneInTheDark]

Ahoj, vyzkoušel jsi přidat si do make.conf následující :

FEATURES="ccache parallel-fetch"

jde hlavně o ten parallel-fetch , balíky co jsou potřeba se na pozadí stahují, zatím co se kompiluje. Příjemně mě to překvapilo. No a ccache asi netřeba rozpitvávat ... :)

[qk]

ano, to pouzivam, ostatne moje features vypadaji takhle FEATURES="ccache distlocks metadata-transfer notitles parallel-fetch sandbox userfetch userpriv usersandbox". Stejne ale s mym pripojenim je problem, ze kompiluju rychleji nez stahuju, proto vytam tyhle delty pro co nejnizsi prenos.

[cenebris]

Kdyz je to tak dobre, proc tento mechanismus neni pouzit standardne u vetsiny distribuci? Znatelne by to zmensilo zatizeni repozitaru. Co jsem cetl na strankach projektu tak to neni omezeno pouze pro gentoo.

[Käyttäjä 11133]

Protože je to sice méně náročné na traffic, ale zase potřebuješ více místa kde ty diffy uskladníš.

[cenebris]

Vice mista na serveru nebo u uzivatele?

[Käyttäjä 11133]

Na serveru. U uživatele stačí opatchovat původní tarball a poté ten diff smazat.

[brk]

Tyhle servery generovaly, co si pamatuji z dob, kde jsem je používal, patche dynamicky. Poslal si serveru požadavek obsahující jakou verzi máš, jakou chceš a on podle potřeby stáhl obě dvě verze, udělal patch a ten poslal zpět. Pokud má program deset verzí, ty máš verzi 5, tak server ti byl schopný vyrobit patch na verzi 1-4 a 6-10, tedy devět různých patchů. Ty ale můžeš mít libovolnou z deseti verzí a říct si o patch na další, takže server je schopný vyrobit 90 patchů. Běžné patche se hýbou třeba někde kolem 5ti%, ale čím je větší rozestup mezi verzemi, tak tím narůstá jejich velikost a v tomto množství i požadavek na diskovou kapacitu.

Navíc tahle sranda je už i celkem náročná na výpočetní výkon, takže když si někdo „hrál“ a nechal si vyrobit pár zbytečných patchů mezi verzemi Open Office, tak server byl den schopný tak akorát posílat to co měl někde v „cache“ dříve vyrobených patchů.

[Käyttäjä 11133]

Právě proto se ty vyrobené patche ukládají, aby to nebylo ta náročné na výpočetní výkon a tedy je to náročné na prostor na serveru. Při prvním požadavku se ten patch vygeneruje a při druhém požadavku o stejný patch se už jen pošle adresa toho vytvořeného.

[brk]

Jasně že jo, ale dnes mi to připadá jako podružný problém. Neříkám, že bych občas nevyužil rychlejší počítač, ale zatím mi tak nějak můj 2GHz Celeron stačí a při 2Mbps lince stáhnu rychleji celý program znovu, než se mi původní verze opatchuje. U 600kbps linky to bylo tak nějak na hraně a občas jsem s tím ještě koketoval, ale od 1Mbps nahoru to už pro mne nemělo smysl.

[Käyttäjä 11133]

Mám 256kb/s

[qk]

no pro mne s GPRS (jede to kolem 50kb/s) je to celkem vyhodny...a myslim ze i pro lidi s malym FUP (treba 1 GB) je to urcite zajimavy.

[Michal Kubeček]

To je asi věc každé distribuce. Třeba v SuSE jsou delty defaultní od chvíle, kdy se objevily (určitě přinejmenším 9.3 (podzim 2005), ale řekl bych, že to bylo už o jednu nebo dvě verze dřív), naopak u 10.1 v rámci rozsáhlých změn package managementu nějak zapomněli, že by bylo dobré nechat možnost je vypnout…

[qk]

Tak jeden priklad kolik sem ted usetril, update ultimatestuns, normalni stazeni 14 694KB, stazeni pres delta update 1,804,183 (1.7M).