Yum-presto (deltarpm)

[Adi1981]

Niedawno na liście mailingowej → fedora-devel pojawił się ciekawy wątek a w nim pewny dodatek do yuma, mianowicie yum-presto. IMO może on zrewolucjonizować działanie yuma i przyczynić się dość znacznie do rozwoju fedory, więc zapraszam do zapoznania się z wątkiem i pomocy autorowi w testowaniu i wykrywaniu błędów.

 

Plugin ten pozwala na ściąganie w miejce updatowanych rpm-ów tylko ich plików delta, czyli coś na zasadzie diffa do poprzedniej wersji. Po ściągnięciu plików drpm tworzy on na lokalnym systemie całe paczki rpm a następnie je aktualizuje w systemie. Ściągając drpm-y oszczędzamy sobie kilkadziesiąt, do kilkuset MB danych do ściągnięcia (w zależności od wielkości i liczby updatowanych pakietów).

 

Najlepiej zobrazować to można pokazując wyniki działania yum-presto:

Size of all updates downloaded from Presto-enabled repositories: 14863066 bytes
Size updates would have been downloaded if Presto wasn't enabled: 127561826 bytes
This is a savings of 89 percent

ściągnięte 14.8MB zamiast 127.5MB oraz

Size of all updates downloaded from Presto-enabled repositories: 9462610 bytes
Size updates would have been downloaded if Presto wasn't enabled: 51496768 bytes
This is a savings of 82 percent

ściągnięte 9.4MB zamiast 51.4MB

 

Paczki można pobrać → stąd.

 

Zapraszam do testowania i pomocy przy rozwoju tego projektu

[InIrudeBwoy]

Ciekawa sprawa. Jakie są minusy używania tego pluginu? Oprócz ewentualnych błędów.

 

Mam nadzieję, że udostępnia to dla wersji x86_64. Wtedy z miła chęcią przetestuję.

[exbros]

Pomysl dobry, ale IMHO - mocno spozniony.

Za takie narzedzie w czasach laczenia sie z zawrotna predkoscia 33600 przez modem analogowy i dial-up oddal bym zycie i pol renty, ale dzis?...

 

W czasach szybkiego szerokopasmowego dostepu do sieci pomysl malo interesujacy. W moim przypadku pobranie 120MB trwa ponizej 2 minut a obawiam sie, ze sciagniecie 15MB + obrobka kilkudziesieciu pakietow (dodanie diffow) trwala by co najmniej dwukrotnie dluzej. Tak, mam szybkie lacze i wolny komputer...

 

Mysle, ze prace developerskie w dzisiejszych czasach powinny pojsc raczej w strone optymalizacji kodu i usprawnienia i przyspieszenia dzialania tandemu yum + rpm jak tez jego wzbogacania o nowe funkcje.

 

Choc rozumiem, ze uzytkownikom z wolnymi laczami i malymi limitami moze sie to spodobac.

Pozdro

[Adi1981]

minusy to jedynie to co wspomnial exbros, czyli czas obudowy pelnego rpm-a ale wcale nie jest to az tak strasznie dlugi czas, zwlaszcza ze, parafraujac slowa exbrosa, i tak wiekszosc ludzi ma dzisiaj porzadny i szybki sprzet

Z tego co bylo napisane to planowana tez jest wersja x86_64, ale kiedy sie ukaze nie mam pojecia

 

Co do lacza owszem, duzo ludzi ma szerokopasmowy net, ale nie zapominaj ze jednak znaczna wiekszosc w polsce to ludzie posiadajacy najczesciej lacza 128kbit - 512 kbit (czesto radiówke) gdzie sciagniecie 10 MB zamiast 150MB robi (_na prawde_ → naprawdę) ORT SPORA róznice. Nawet jesli ktos ma wieksze lacza, to zazwyczaj sa one dzielone na kilka osób. Polska to niestety nie stany gdzie standardem jest w zasadzie 6mbit na osobe.

 

Natomiast co do procka.. ja mam 600MHz i jakos nie odczulem az tak wielkiego przyrostu czasu podczas budowania pakietu, sciaganie danych by zajelo dluzej. Przy laczu 2mbit sciagniecie 150 MB by zajelo ok 20 minut (przy pelnym transferze, bez przeciazonych mirrorów, dzielenia lacza itp...). Poza tym nie chodzi juz o to ze my sobie sciagniemy te 100 MB w 2 czy 20 minut. Sciagniecie 10 MB zamiast 100 znacznie odciaza sieci szkieletowe, serwery itd. I w ty kierunku wszystko powinno chyba isc zeby zmniejszac utylizacje lacz. Prosty przyklad z reszta: FC6 sciagnieto ponad 1mln razy. Zakladajac ze nawet chocby 1000 userów bedzie chcialo pobrac uaktualnienia (dajmy na to 100MB) mniej wiecej w jednym czasie, to serwery maja do wyslania w tym momencie 100GB danych. Z pluginem byloby to ok 10GB. Róznica spora...

 

Co do samego yuma to owszem, takie prace caly czas trwaja majace za zadanie optymalizacje kodu i przyspieszenie yuma (kto ma f7 z yum 3.1.x wie chyba o czym mówie ). Porzadnie odnowiony silnik, korzystanie z sqlite itd. Oczywiscie na obecnym etapie z tego co mozna sie dowiedziec na listach jest sporo jeszcze do zrobienia w tym temacie (zwlaszcza deps resolving - zajmuje cale godziny jak na razie) ale w wydaniu stabilnym powinno byc juz wsio ok i userzy powinni poczuc znaczny przyrost wydajnosci. A w polaczeniu z yum-presto kto wie czy yum nie bedzie mógl konkurowac pod wzgledem szybkosci dzialania z aptem Pozyjemy zobaczymy.

 

ps. nad yum-presto pracuja zupelnie inni developerzy niz nad yumem, z reszta z tego co zrozumialem to projekt ten tworzy osoba raczej nie zwiazana z devami fedory/redhata

[InIrudeBwoy]

Przychylam się do zdania Adiego, że to duże odciążenie dla sieci czyli dla dobra wspólnego jednak martwi mnie to co napisał exbros. Ciekawe jakby to wyglądało w wypadku dużych rpm-ów? jak długo by trwało budowanie rpm-a?

 

To nie zmienia faktu, że jak pojawi się wersja dla 64bitowych systemów to się zabiorę do testowania.

[Karlik]

InIrudeBwoy: nie zaglebialem sie w architekture plików delty, ale czas budowy pakietu wynikowego raczej zalezalby od wielkosci zmian a nie od wielkosci samego programu.

[tomasiek]

Zazwyczaj korzystam ze smarta (łatwiej wyszukuję pakiety) ale postanowiłem spróbować tego dodatku do yum. Efekt - dziś do zaktualizowania wybiło mi m.in. openoffice - w smarcie i w czystym yum - do ściągnięcia ~132,2 MB - w presto tylko 22 MB (!). PRzy moim łączu ściąganie trwa gdzieś o 50 min krócej. Czas instalacji - niby ciut dłużej, ale w sumie - o wiele szybciej - bo dużo zaoszczędził na ściąganiu....

 

[Adi1981]

Dodam jeszcze, ze z tego co zdazylem zauwazyc presto dziala tylko dla repozytoriów extras i updates, tak wiec paczki spoza tych repo sa sciagane w calosci, stad moze byc dodatkowych kilka MB podczas sciagania. Co oczywiscie nie zmienia faktu ze chyba warto jest go zainstalowac

 

Jesli chodzi o czas odbudowywania pakietów niestety nie zwrócilem uwagi ile trwalo odbudowanie openoffice'a, delta miala 22 MB, wiec byla calkiem spora, inne maja zazwyczaj kilkaset kB, wiec to by w jakis sposób obrazowalo ile czasu potrzeba na przebudowanie pakietu.

 

ps. Wyszla wersja 0.3.0

[exbros]

Natomiast co do procka.. ja mam 600MHz i jakos nie odczulem az tak wielkiego przyrostu czasu podczas budowania pakietu, sciaganie danych by zajelo dluzej. Przy laczu 2mbit sciagniecie 150 MB by zajelo ok 20 minut (przy pelnym transferze, bez przeciazonych mirrorów, dzielenia lacza itp...). Poza tym nie chodzi juz o to ze my sobie sciagniemy te 100 MB w 2 czy 20 minut. Sciagniecie 10 MB zamiast 100 znacznie odciaza sieci szkieletowe, serwery itd. I w ty kierunku wszystko powinno chyba isc zeby zmniejszac utylizacje lacz. Prosty przyklad z reszta: FC6 sciagnieto ponad 1mln razy. Zakladajac ze nawet chocby 1000 userów bedzie chcialo pobrac uaktualnienia (dajmy na to 100MB) mniej wiecej w jednym czasie, to serwery maja do wyslania w tym momencie 100GB danych. Z pluginem byloby to ok 10GB. Róznica spora...

Zgadzam sie z Toba w niemal 100%-ach

 

 

[1.a] Uscislajac: w optymalnych warunkach sciagniecie 150MB powinno zajac nie wiecej niz 10 minut ...

 

[2.a] przyjmijmy, ze takie 150MB updateow to 125 pakietow - wiec do czasu potrzebnego na download dolozmy 2 sekundy na zakonczenie i zainicjowanie kazdego pojedynczego transferu = dodatkowe 4 minuty (!!)

 

W sumie [.a], sciagniecie 125 pakietow o lacznej wielkosci 150MB powinno zajac 14 minut (od przyklepania y w yumie do uruchomienia instalacji)

 

 

[1.b] przyjmujac, ze sredni zysk na metodzie przyrostowej to 85%, ze 150MB pozostaje Ci do sciagniecia 22.5MB - powinno to zajac 1.5 minuty

 

[2.b] nadal masz do sciagniecia 125 pakiecikow ... wiec dodaj extra te same 4 minuty na zakonczenie i zainicjowanie transferu

 

W sumie [.b], sciagniecie 125 pakietow o lacznej wielkosci 22.5MB powinno zajac 5.5 minuty (od przyklepania y w yumie do uruchomienia procesu patchowania rpm-ow) i teraz trzeba dokonac kilku dodatkowych zabiegow zanim rozpocznie sie instalacja

 

8.5 minuty roznicy... dla jednych to duzo, dla innych malo

 

Przyjmijmy, ze srednio na spatchowanie pojedynczego rpma proces bedzie potrzebowal 4 sekundy - nie wiem na ile sluszne jest to zalozenie, poniewaz maly rpm prawdopodobnie moze byc obsluzony w sekunde... ale duzy? ... typu kernel? ... ze, o OOo juz nie wspomne

... dochodza tu opoznienia na ktore w zasadzie nie ma wplywu predkosc proca / ilosc ramu (typu: dostep do dysku i wyszukiwanie porozrzucanych plikow). Nalezy tez pamietac, ze oprocz samego procesu patchowania potrzebne beda co najmniej dwa dodatkowe procesy - przygotowanie oryginalnego rpma i sprawdzenie poprawnosci pobranego diffa

No i dochodzimy do sedna sprawy - patchowanie 125 pakietow zajmie 10 minut - i jestesmy na minusie

 

 

Co do oszczedzania sieci i wspolnego dobra - to IMHO walka z wiatrakami.

Dopoki setki tysiecy (setki milionow ?) uzyszkodnikow wszelkiej masci sieci wymiany plikow p2p nie przestana ciagnac filmow, muzy, gierek, obrazow spiraconych systemow i softu oraz pr0now to takie dobrowolne samoograniczanie sie grupki uzytkownikow wyglada po prostu smiesznie. Sorry za szczerosc.

 

 

No i na koniec, zeby nie bylo ze tylko krytykuje

Poza faktami ktore staralem sie pokazac powyzej z cala reszta sie zgadzam i uwazam ze to bardzo ciekawy projekt.

Mysle, ze faktycznie bardzo zadowoleni z niego beda uzytkownicy wolnych radiowek, wolnego dostepu do sieci a szczegolnie Ci z niskimi limitami - chociaz limity to juz chyba przeszlosc nawet w Polsce?

 

Sorry, za ten przydlugi i zagmatwany wywod, ale przeszkadzaja mi tu w pracy (ciagle zawracajac glowe jakimis glupotami, jakby nie wiedzieli ze musze sie poprodukowac na forum ) i pisze tego posta z przerwami juz chyba ponad godzine... w miedzyczasie pojawilo sie juz troche nowych opinii i uwag w tym watku, ale nie bede juz zmienial tego co z takim trudem wypocilem

Pozdro

 

 

//===== edit =====

Poprawilem wyliczanki dla patchowania...

Sprawdzilem rozmiar - srednia wielkosc pakietu dla core to 1.4MB a dla extras 1.1MB, dla wszystkiego razem to 1.2MB, a wiec 150MB to ~125 pakietow...

[Adi1981]

Z tą jedną malą poprawką, że 300 pakietów to zdecydowanie więcej IMO niż 150MB, a dodatkowo 150 MB nie u każdego będzie się ściagalo 20 minut - patrz post tomasiek-a; zaoszczędzone ok. 50 minut ściągania przy 130MB

Nawet jeśli to byłoby 300 pakietów, to musiałyby one mieć góra po 0.5MB, a co za tym idzie drpm-y by były jeszcze mniejsze, a więc i czas ich nakładania i budowania całej paczki rpm byłby zdecydowanie krótszy.

 

Natomiast do sprawdzenia poprawności diffa (z tego co udało mi się wyczytać) jest wykorzystywany mechanizm sprawdania poprawności pakietów zaimplementowany w yumie, więc tutaj czas powinien być ten sam co przy tradycyjnym ściąganiu. Z resztą najlepiej myślę że będzie po prostu przeprowadzić jakiś maly teścik który dokładniej zobrazuje co jest lepsze I jeśli faktycznie z testów wyjdzie ze czas odbudowania pakietu jest krótszy niż ściągnięcia go z netu, dodając do tego optymalizacje po ukazaniu się stabilnego yum-3.1.x, może się okazać że yum w końcu będzie całkiem szybkim narzędziem do zarządzania pakietami.

[tomasiek]

no te 50 minut to przy założeniu że:

1. sieć osiedlowa na maksa obiążona (czyli w godzinach od 15 do 20 - dzieciaki siedzą) - wtedy około 1h na ~ 150 MB. Wieczorami jest o niebo lepiej (wtedy 150 MB w 30 minut). W ogóle to używałem smarta bo IMO działał szybciej niż yum.

2. dziś te 22 mb ściągało się ~10 minut (w godzinach ~ 16-17) = wniosek zaoszczędzone 50 minut i mniejsze obciążenie łącza. Admin nie będzie się wściekał że jakieś dziwactwa ściągam (gdyby to były filmy to pewnie by się nie czepiał )

3. wydaje mi się że czas nakładania pakietów jest porównywalny do tego który był w przypadku (_yum'a_ → yuma) ORT. Nie zauważyłem przynajmniej żeby jakoś znacząco się wydłużył.

4. IMO? ciekawe rozwiązanie które "przyśpieszy" u takich jak ja np. upgrade całego systemu bezpośrednio po instalacji np u sąsiada - zamiast 400 MB - ściągnie 50 MB... czy nawet 100 MB.

 

[thof]

Przed chwilą zainstalowałem świeżą fedore i postanowiłem zaktualizować ją używając tego "cuda". Na początku wszystko dobrze 192 pakiety ok 125mb do ściągniecia. Po ściągnięciu pakietów rozpoczęła się ich przebudowa, ale zauważyłem, że co jakiś czas pojawia się komunikat "Error rebuilding rpm from <nazwa pakietu>! Will download full package." Po skończeniu okazało się, że pakietów które muszą zostać ściągnięte w całości jest 116! Z założenia miałem dzięki yum-presto zaoszczędzić czas, a efekt był zupełnie odwrotny Nie dlaczego tak się stało, może to jest po częsci moja wina bo użyłem wersji 3.2, która jest w fazie testów?

[Adi1981]

presto tak wlasnie dziala z zalozenia - sciaga drpma, sprawdza jego integralnosc i jesli wykryje ze drpm jest uszkodzony, tak ze przebudowa pakietu z takiego drpma bylaby niemozliwa lub niebezpieczna dla systemu, to wtedy sciaga calego (_rpma_ → RPM-a) ORT i instaluje jego. Co moze byc tego przyczyna nie wiem, moze jakies problemy z siecia, moze zle zrobione drpmy, moze blad w programie, moze problemy z repozytorium presto - jest, albo jeszcze niedawno bylo, hostowane na jakims prywatnym serwerze, a drpmy tworzone sa jakims skryptem (tez we wczesnej wersji beta ). W zalozeniu autora jest aby w przyszlosci wszystkie repozytoria tworzyly swoje wlasne oficjalne repo drpm.

 

Poza tym jak napisalem wczesniej... to jest nowy projekt, rozwijany od kilku dni i nie jest on jeszcze stablny, duzo pracy jeszcze zostalo autorowi, wiec nie narzekajcie ludzie ze cos nie dziala czy ze zle dziala, tylko dajcie o tym znac autorowi! Nie oczekujcie ze jak zainstalujecie jakas wczesna wersje alfa jakiegos programu to ze wszystko bedzie dzialalo cacy ! Temat ten zamiescilem na forum abyscie mieli maly feedback tego programu, ale przede wszystkim abyscie pomogli w jego testowaniu i wykrywaniu bledów.

[kiewball]

A moje zdanie jest takie, że nawet gdyby to nie przyśpieszyło sprawy, to i tak warto bo ograniczamy ruch w sieci

[InIrudeBwoy]

A moje zdanie jest takie, że nawet gdyby to nie przyśpieszyło sprawy, to i tak warto bo ograniczamy ruch w sieci

Prometejska postawa.

Podpisuje sie pod tym