InfoNarzędzia dla geokeszera

[ted69]

Problemem jest, że niektóre urządzenia (np mój nie taki stary SE K750i) nie wyświetla co większych stron, ew ładuje bardzo długo... więc może być to problem.

i to nie jeden problem - to jest pewne. Ludzie maja rozne sprzety, z roznymi OS.
Podejrzalem wlasnie jak wyglada taka baza zrobiona przez GSAKa )export w HTMLu) - wszystko hurtem wrzuca do jednego katalogu

[Bas]

napisalem ciut wyzej

No bo wydaje mi się, że kompresja wbudowana w rsync jest bardziej efektywna niż zip ?

1.
ciut wyzej dotyczylo zapakowania bazy Filipsa w foldery, zeby nie bylo tysiecy plikow w jednym katalogu. Program jest gotowy

2.
Przede wszystkim chodzi o ILOSC plikow do synchronizacji. Dopiero co zostalo udowodnione, ze oplaca sie pobrac skrzynki w paczce, niz synchronizowac je plik po pliku chocby nawet z lepsza kompresja.

3.
nie wiedzialem, ze pojedyncze pliki sa kompresowane
Sa ?

Tak, czy inaczej mysle, ze oplaca sie pobrac 400 skrzynek w jednym pliku, niz synchronizowac je jeden po drugim

[Bas]

1. synchronizowany z zipem u usera na komputerze
2. niektóre urządzenia [...] nie wyświetla co większych stron, ew ładuje bardzo długo

1.
czy rsync zostawia u usera jakis znacznik - timestamp po udanej synchronizacji?
Caly czas chodzi mi po glowie, zeby user pobieral automatycznie skrzynki w zipie od czasu ostatniej aktualizacji. Tylko ze:
- jest to po czesci zarzucenie rsync
- personalizacja. Moze wygodniej utworzyc plik zip ze skrzynek z 3 dni dla wszystkich?
Niewatpliwie te pomysly wynikaja z braku znajomosci rsync. Widze tylko co sie dzieje podczas synchronizacji: najpierw mielenie bazy kilkunastu tysiecy plikow, co jest czasochlonne, a pozniej pobieranie pojedynczych plikow... bardzo dlugie. Sadze, ze pobranie kilkuset plikow jednorazowo, chocby z automatu, przyspieszyloby chociaz ten drugi etap.

2.
tak, to prawda. W telefonach szczegolnie.
Ladnie otwieraja sie pliki do 20kB. Problem jest z plikami (prosty html bez zadnych zagniezdzonych tabel...) > 80kB. Tak przynajmniej widze w N80.
Mediana dla bazy skrzynek to 4.6kB (tak mniej wiecej), a jedynie 120 plikow ma ponad 10kB - to tez jest otwierane bez problemow.

[shchenka]

nie wiedzialem, ze pojedyncze pliki sa kompresowane
Sa ?

Są kompresowane "w locie" i rozkompresowywane od razu przy odbiorze, jeśli używasz opcji -z. Można także ustawić poziom kompresji za pomocą opcji --compress-level

Tak, czy inaczej mysle, ze oplaca sie pobrac 400 skrzynek w jednym pliku, niz synchronizowac je jeden po drugim

Chyba tak. Chociaż ciekawie byłoby, gdyby rsyncować tar ze wszystkimi plikami html.

Co do rsynca, to potrafi używać dużo pamięci, może to też przyczynia się do wolnego działania ? (jeśli na przykład nie ma dużo wolnej fizycznej pamięci na serwerze)

[shchenka]

Caly czas chodzi mi po glowie, zeby user pobieral automatycznie skrzynki w zipie od czasu ostatniej aktualizacji.

Ale co ze starymi skrzynkami, w których na przykład coś się zmieniło w opisie, albo doszedł tylko nowy wpis do logu ?

Nawiasem mówiąc, czy udało się komuś uruchomić klienta rsync na symbianie ?
Mi udało się tylko demona

[Bas]

Są kompresowane [...] jeśli używasz opcji -z. Można także ustawić poziom kompresji za pomocą opcji --compress-level

mam tak:
rsync.exe --archive --update --skip-compress=jpg/png --stats --log-file=rlog.txt --human-readable --times --progress --recursive --timeout=600 %BEZ_GPX% %BEZ_OBRAZKOW% ocpl@achjoj.info::oc %OC_DEST%

wydaje mi sie, kiedys widzialem " --compress-level"
teraz jest "--skip-compress=jpg/png"
czyli... nie kompresuje html czy moze robi to domyslnie?

[shchenka]

Spróbuj dodać do tego --compress i zobacz czy jest różnica. Jpegów faktycznie nie warto kompresować, bo już są skompresowane, ale wydaje mi się, że filips wyłączył już to po stronie serwera.

Aha, i usuń sobie opcję --progress, spowalnia działanie po stronie klienta.

--times możesz też wyrzucić, bo --archive już to załatwia.

Podejrzewam, że wyrzucenie --log-file też może trochę przyśpieszyć sprawę.

[Hern]

wydaje mi sie, kiedys widzialem " --compress-level"
teraz jest "--skip-compress=jpg/png"
czyli... nie kompresuje html czy moze robi to domyslnie?

Wydaje mi się, że kompresuje domyślnie, chociaż obserwując przesyłanie pliku ponad 200kB mam pewne wątpliwości ...
Natomiast wyłączenie kompresji dla obrazków typu jpg czy png ma głęboki sens. Kompresja spowodowałaby transfer większych plików i niepotrzebne obciążenie procesora serwera.

[Bas]

wyłączenie kompresji dla obrazków typu jpg czy png ma głęboki sens

no, tak. To akurat jest oczywiste
Uznalbym jednak, ze to z powodu straty czasu na kompresje/rozpakowanie pliku, ktory i tak w zalozeniach jest "scisniety".
PNG nawet dadza sie kompresowac (do 10%), ale zbyt malo zeby to mialo istotne znaczenie.

@shchenka:
wyprobuje nowe ustawienia. Zrobie jakis maly test

[Bas]

Po poludniu zrobilem aktualizacje - bez problemu.

A w nocy chcialem zrobic jeszcze raz. Rsync chce aktualizowac sam siebie i na tym sie wyklada.

2008/08/01 00:19:41 [2296] >f.stp..... rsync/cygwin1.dll
2008/08/01 00:19:41 [2296] rsync: rename "/cygdrive/d/adres/rsync/.cygwin1.dll.goyvGn" -> "rsync/cygwin1.dll": Permission denied (13)
2008/08/01 00:19:41 [2296] >f.st...... rsync/oc-update.bat
2008/08/01 00:19:41 [2296] >f..tp..... rsync/oc-update.sh

2008/08/01 00:19:41 [3800] rsync error: some files could not be transferred (code 23) at main.c(1497) [generator=3.0.2]

Proba ponownego uruchomienia rsync: komunikat "odmowa dostepu"

Pobralem rsync zipem ze strony Filipsa, ale i tak rsync ponownie chce sie aktualizowac i pada...

[ted69]

Wlasie zapuscilem synchronizacje - jak zawsze i mam podobny objaw.
W katalogu "oc", pojawil sie nowy podkatalog - "rsync" do ktorego w trakcie pierwszej synchronizacji sciagane sa nastepujace pliki:

Kod: Zaznacz cały

Wolumin w stacji C nie ma etykiety.
 Numer seryjny woluminu: 9867-19F8

 Katalog: C:\Turystyka\OC_Update\oc\rsync

2008-07-31  20:51    <DIR>          .
2008-07-31  20:51    <DIR>          ..
2008-04-11  14:03           999Ăż424 cygiconv-2.dll
2008-04-11  14:03            31Ăż744 cygintl-3.dll
2008-04-11  14:03         1Ăż873Ăż396 cygwin1.dll
2008-04-11  14:03            66Ăż048 cygz.dll
2007-08-22  23:08            18Ăż009 gpl2.txt
2007-08-23  10:04             3Ăż404 howto.txt
2008-07-31  20:49             1Ăż413 oc-update.bat
2007-08-16  17:21             1Ăż426 oc-update.ico
2008-07-31  20:50               369 oc-update.sh
2008-04-11  13:25           346Ăż112 rsync.exe
2008-07-02  21:50                 8 rsync_password
              11 plik(¢w)       3ÿ341ÿ353 bajt¢w

Zapuszczona po raz drugi synchronizacja przeszla BEZ problemow.

[filips]

Mea culpa!

Wczoraj robiłem próby z paczką zipową, no i się widać zagalopowałem.

Proszę zatem o wstrzymanie się do wieczora/popołudnia....

/F

[Bas]

W katalogu "oc", pojawil sie nowy podkatalog - "rsync"

Ja uruchamiam rsync z katalogu rsync - teraz juz sie nie dziwie, ze nie chcial sie zaktualizowac

[filips]

Proszę zatem o wstrzymanie się do wieczora/popołudnia...

No i powinno być ok.

Z nieco innej beczki. porobiłem testy, jak by było, gdyby baza była w jednym zipie. Wygląda na to, że synchronizacja (a w zasadzie sam transfer) była by szybsza. Ale nie wiem, jak do końca to rozwiązać taktycznie. Bo tak:

1) odpalamy rsynca
2) pobiera się zip, ktory musi lądować w jakiejś lokalizacji np na twardym dysku (chyba, że ktoś ma dużo miejsca na karcie pamięci). Nie można go jednak usunąć, bo za następnym razem trzeba będzie ściągnąć wszystko od nowa, a nie tylko różnice.
3) z niego extraktowane są nowe pliki do bazy

problem jest taki, że 1) właśnie trzeba trzymać tego zipa w jednym i tym samym miejscu (np na jednym komputerze) albo zajmować miejsce na karcie pamięci 2) z tego, co zauważyłem, rsync tworzy na dysku "obraz" pliku, który ściąga - więc powstaje drugi plik o dużej objętości. w chwili obecnej konieczne było by zatem posiadanie 2x165MB wolnego na karcie. A to już sporo...

Co sądzicie?


Moje osiągi przy synchronizancji zipa:

Kod: Zaznacz cały

Number of files: 2
Number of files transferred: 1
Total file size: 131.37M bytes
Total transferred file size: 131.37M bytes
Literal data: 3.83M bytes
Matched data: 127.55M bytes
File list size: 56
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 80.19K
Total bytes received: 3.87M

sent 80.19K bytes  received 3.87M bytes  64.26K bytes/sec
total size is 131.37M  speedup is 33.24

Gdyby ktoś chciał popróbować, zobaczcie:

Kod: Zaznacz cały

rsync.exe --archive --update --stats --human-readable --times --progress --recursive --timeout=600 ocpl@achjoj.info::oc-zip-full ./

[Bas]

Hmmm, do pobierania pelnej bazy rsync w ogole nie jest potrzebny, bo i tak baza w zipie jest pelna. Poza tym ILE osob bedzie z tego korzystac? ILE razy? Wydaje mi sie, ze tylko raz i tylko nowy uzytkownik, wiec moze powiesic pelna baze na serwerze i dac link - jesli juz w ten sposob.

Pomysl mialem inny.
Myslalem, zeby najpierw w paczce zip pobierac pliki nowe z ostatnich np. 3 dni -> rozpakowac je do foledru oc, a zip skasowac (wtedy sie da) i dopiero wtedy -> uruchomic rsync. W efekcie do przeslania pozostana niedobitki jakies/zguby.
Jesli ktos synchronizuje baze codziennie, to odpali bat z normalnym rsync
Jesli ktos synchronizuje rzadziej, to uruchomi bat "3-dniowy".

Przykladowy ruch w interesie:

.
Bieżąca synchronizacja: 2008-07-29 Wt
cache- update 104
nowe obrazki 14


Bieżąca synchronizacja: 2008-07-30 Śr
cache- update 97
nowe obrazki 6

Bieżąca synchronizacja: 2008-07-31 Cz
cache- update 85
nowe obrazki 19

Bieżąca synchronizacja: 2008-08-01 Pt
cache- update 72
nowe obrazki 33

Dane nie sa pelne, bo troche sie bawilem, ale mniejsze nie sa