From: Alexey Tourbin <at@altlinux.ru> To: devel@lists.altlinux.org Subject: Re: [devel] comprehensive rsyncability test Date: Sun, 1 Jun 2008 14:18:58 +0400 Message-ID: <20080601101858.GF7996@solemn.turbinal> (raw) In-Reply-To: <20080531185847.GZ7996@solemn.turbinal> [-- Attachment #1: Type: text/plain, Size: 2366 bytes --] Перейду к инетпретации результатов тестирования. 1) Численный аспект тестирования отвечает на ворос, какой объем нужно скачать, чтобы синхронизировать новые x86_64 пакеты за один месяц. $ perl -le 'print "|".("-"x(2434968/2434968*78))."|"' |------------------------------------------------------------------------------| таков общий объем новых файлов, пожатых гзипом. $ perl -le 'print "|".("-"x(1643033/2434968*78))."|"' |----------------------------------------------------| столько скачал бы rsync, если новые И старые файлы пожать в rsyncable deflate. $ perl -le 'print "|".("-"x(1960275/2434968*78))."|"' |--------------------------------------------------------------| столько пришлось бы скачать, если новые файлы пожать с помощью 'lzma -2'. $ perl -le 'print "|".("-"x(1819361/2434968*78))."|"' |----------------------------------------------------------| столько пришлось бы скачать, если новые файлы пожать с помощью 'lzma -5'. Таким образом, численно rsync сохраняет преимущество, но наглядная интерпретация показывает, что LZMA перекрывает большую часть выгоды, которую даёт rsync, так что сравнительное преимущество rsync оказывается небольшим. 2) Рассмотренный численный аспект проблемы -- не единственный, хотя и наиболее важный. Следует спрашивать не только "сколько нужно скачать", но и учитывать также, "сколько это в конечном счёте будет занимать места на диске". Если правомерно считать вопрос storage следующим по актуальности после вопроса trnasfer, то LZMA здесь показывает серьёзное преимущество: |------------------------------------------------------------------------------| |----------------------------------------------------------| 3) Конечно, есть ещё один аспект проблемы. LZMA даёт прямое преимущество, потому что уменьшение размера файла напрямую влияет на объем для скачивания; а rsyncability даёт только косвенное/ гипотетическое преимущество. Чтобы преимущество rsync могло реализоваться, должны быть выполнены три условия: у пользователя есть старые файлы; старые файлы пожаты в rsyncable deflate; и пользователь правильно организовал процесс синхронизации. Этот аспект проблемы трудно оценить численно, но он является достаточно важным. Таким образом, я считаю, что в вопросе "rsyncable deflate vs LZMA" ни один из вариантов не имеет решающих преимуществ. [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2008-06-01 10:18 UTC|newest] Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-05-31 18:58 Alexey Tourbin 2008-05-31 19:44 ` Dmitry V. Levin 2008-05-31 21:32 ` Alexey Tourbin 2008-05-31 21:57 ` Dmitry V. Levin 2008-05-31 22:14 ` Alexey Tourbin 2008-05-31 22:26 ` Dmitry V. Levin 2008-05-31 23:10 ` Alexey Tourbin 2008-06-01 8:11 ` Alexey Tourbin 2008-06-01 17:35 ` Michael Shigorin 2008-06-01 17:43 ` Mikhail Gusarov 2008-06-01 18:04 ` Michael Shigorin 2008-06-01 18:39 ` Alexey I. Froloff 2008-06-01 17:44 ` Alexander Bokovoy 2008-06-01 18:22 ` Alexey Tourbin 2008-06-01 18:32 ` Led 2008-06-01 19:04 ` Alexey Tourbin 2008-06-01 10:18 ` Alexey Tourbin [this message] 2008-06-01 12:18 ` Anton Farygin 2008-06-01 13:23 ` Mikhail Gusarov 2008-06-01 12:26 ` Anton Farygin 2008-06-01 13:48 ` Alexander Bokovoy 2008-06-01 21:17 ` [devel] rsync server load Alexey Tourbin 2008-06-01 21:52 ` Konstantin A. Lepikhov 2008-06-02 14:08 ` Dmitry V. Levin 2008-06-02 14:25 ` Konstantin A. Lepikhov 2008-06-02 14:29 ` Dmitry V. Levin 2008-06-02 18:04 ` Konstantin A. Lepikhov 2008-06-02 20:21 ` [devel] [jt] " Dmitry V. Levin 2008-06-02 20:28 ` Alexey Gladkov 2008-06-02 20:35 ` Dmitry V. Levin 2008-06-02 20:41 ` Alexey Gladkov 2008-06-02 20:58 ` Sergey Y. Afonin 2008-06-03 6:30 ` Dmitriy M. Maslennikov 2008-06-02 20:53 ` Sergey Y. Afonin 2008-06-02 21:33 ` Konstantin A. Lepikhov 2008-06-02 21:42 ` Dmitry V. Levin 2008-06-02 22:25 ` Konstantin A. Lepikhov 2008-06-02 22:50 ` [devel] [jt] clustered fs Dmitry V. Levin 2008-06-02 22:54 ` Konstantin A. Lepikhov 2008-06-02 23:08 ` Dmitry V. Levin 2008-06-03 5:38 ` Anton Farygin 2008-06-03 7:19 ` Serge Ryabchun 2008-06-03 8:53 ` Michael Shigorin 2008-06-03 10:27 ` [devel] " Dmitry V. Levin 2008-06-03 15:02 ` Michael Shigorin 2008-06-03 15:18 ` [devel] lustre Dmitry V. Levin 2008-06-03 20:21 ` Michael Shigorin 2008-06-03 21:27 ` Dmitry V. Levin 2008-06-04 12:15 ` Serge Ryabchun 2008-06-04 12:20 ` Michael Shigorin 2008-06-04 12:47 ` Anton Farygin 2008-06-04 14:17 ` Andrey Brindeyev 2008-06-04 14:17 ` Andrey Brindeyev 2008-06-04 14:46 ` Anton Farygin 2008-06-04 15:12 ` Serge Ryabchun 2008-06-04 15:22 ` Andrey Brindeyev 2008-06-04 18:49 ` Anton Farygin 2008-06-04 15:10 ` Alexander Bokovoy 2008-06-05 9:04 ` Sergey Zhumatiy 2008-06-05 9:08 ` Alexander Bokovoy 2008-06-03 10:50 ` [devel] [jt] clustered fs Mykola S. Grechukh 2008-06-03 8:51 ` [devel] [jt] rsync server load Michael Shigorin 2008-06-01 13:49 ` [devel] comprehensive rsyncability test Alexander Bokovoy 2008-06-01 12:55 ` Anton Farygin 2008-06-01 15:35 ` Alexey Tourbin 2008-06-01 16:38 ` Alexander Bokovoy 2008-06-01 16:42 ` Mikhail Gusarov 2008-06-01 16:55 ` Alexander Bokovoy 2008-06-01 17:03 ` Mikhail Gusarov 2008-06-01 17:41 ` Michael Shigorin 2008-06-01 17:47 ` Mikhail Gusarov 2008-06-01 18:07 ` [devel] [JT] насчёт НП-18 Michael Shigorin 2008-06-01 18:11 ` Mikhail Gusarov 2008-06-02 3:48 ` Anton Farygin 2008-06-02 4:50 ` Alexander Bokovoy 2008-06-02 9:45 ` Sergey Bolshakov 2008-06-02 9:52 ` Anton Farygin 2008-06-02 9:57 ` Aleksey Novodvorsky 2008-06-02 10:18 ` Mikhail Gusarov 2008-06-02 10:43 ` Anton Farygin 2008-06-02 20:24 ` [devel] comprehensive rsyncability test Dmitry V. Levin 2008-06-02 20:31 ` Led 2008-06-04 12:33 ` Alexey Tourbin 2008-06-04 12:49 ` Anton Farygin 2008-06-04 13:04 ` Alexey Tourbin 2008-06-04 17:37 ` Michael Shigorin 2008-06-04 18:24 ` Alexey Tourbin 2008-06-04 18:54 ` Michael Shigorin 2008-06-05 7:36 ` Anton V. Boyarshinov 2008-06-04 18:49 ` Dmitry V. Levin 2008-06-02 10:06 ` Alexey Tourbin 2008-06-02 10:38 ` Alexander Bokovoy 2008-06-02 10:46 ` Anton Farygin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20080601101858.GF7996@solemn.turbinal \ --to=at@altlinux.ru \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git