From: Petr Baudis <pasky@suse.cz>
To: git@vger.kernel.org
Subject: Cloning speed comparison, round II
Date: Sat, 12 Nov 2005 16:53:02 +0100 [thread overview]
Message-ID: <20051112155302.GD30496@pasky.or.cz> (raw)
Hello,
here comes another round of the cloning speed comparison. For the
previous round, see
6395 F Aug 13 Petr Baudis ( 2.6K) Cloning speed comparison
Message-ID: <20050813015402.GC20812@pasky.ji.cz>
What do we have here:
git.git: 10267 objects, mostly packed
cogito.git: 99903903 objects, no packs
(But please note that compared to the previous round, there are
probably more unpacked objects lying around in the git.git repository
- actually roughly 1000.)
Latest GIT, latest Cogito, performed by cg-clone to the official
kernel.org hostnames for each transport. 'real' medians from several
tries (number of tries usually at least three, based on their variance):
rsync git+ssh(*) git(**) http
git.git 0m45s 0m34s 5m30s 4m01s (++)
cogito.git 2m09s 1m54s (+) 4m30s 15m11s (only single run)
(*) git+ssh was to master.kernel.org, which was under significant load
from some seemingly runaway gzip process, so that slowed things
down.
(**) The unpacking was slooooooooow yet the load was quite low. This
should be investigated, the native git fetching is much slower
than even HTTP.
(+) There was unusually high variance here - the results range from
0m27s to 2m30s. In all other cases the results for all runs were
very similiar.
(++) Messy - it stalls at 72 objects, then does seemingly nothing for
a long while, then requests a pack. Huh? Also, I saw the
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git/
line about 100 times for the 72 objects (but never after the pack
is fetched, at least).
Conclusion: The GIT protocol has some major problem which is dragging
it down to ridiculous slowness (isn't it supposed to be as fast as git+ssh
or even slightly faster?). rsync unfortunately still provides the fastest
anonymous access. HTTP is better than it was, but especially when fetching
packs, there is a room for improvement - the mysterious stalls should be
eliminated, and it shouldn't get bogged down by repeated silly requests
for alternates lists etc.
Compared to the last round, HTTP is much faster for unpacked object
stores (thanks to parallel fetching), but much slower for packed object
stores - however that can be caused by more objects lying unpacked now
in the git.git repository. git+ssh (back then clone-pack:ssh) is as
fast as usual - the 0m27s case suggests that it would be much faster
for Cogito if master.kernel.org wouldn't be under load.
GIT protocol is the great disappointment. And I kind of hoped that I could
push the rsync deprecation further because of the GIT protocol.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
next reply other threads:[~2005-11-12 15:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-12 15:53 Petr Baudis [this message]
2005-11-12 19:40 ` Cloning speed comparison, round II Linus Torvalds
2005-11-12 19:46 ` Petr Baudis
2005-11-12 20:13 ` Linus Torvalds
2005-11-12 20:31 ` Linus Torvalds
2005-11-12 21:30 ` Petr Baudis
2005-11-12 21:20 ` Petr Baudis
2005-11-12 22:03 ` Linus Torvalds
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=20051112155302.GD30496@pasky.or.cz \
--to=pasky@suse.cz \
--cc=git@vger.kernel.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).