Hi, I've been working on the migration of the perl5 repositories from perforce to git, which is soon to be officially released. We have set up a server with http/git/ssh access, and we had hoped also rsync access. However, it appears that clone using the rsync:// protocol is broken, and now we are discovering that http cloning is extremely slow. I reported our experiences with rsync in a previous mail, and now im reporting the http performance issue. When we strace the clone we observe (to quote our sysadmin): "git seems to be stuck for 10 minutes after downloading" "no output, strace shows it's having sex with the memory allocator" "sex with memory allocator" ==> loads of memory allocation/dealoccation A provisional release of the conversion is available at http://dromedary.booking.com/perl.git We are using git 1.6.0.5 on another more or less equivalent host, with the same problems, and dromedary is using git version 1.6.0.4.724.ga0d3a. However we believe that the problem is actually on the client side. The pack download itself appears to be quite fast, however there is an extremely long pause (minutes) after which a HUGE amount of essentially imcomprehensible output is generated about walking packs or some such. Timing a clone via http gets us number like: real 7m42.459s user 3m42.154s sys 0m12.641s Wheras using the git:// protocol gets us times like: real 4m6.162s user 0m43.595s sys 0m4.852s The client these numbers are from is git version 1.6.0.3. So it take approximately twice the time via http as it does via git. This seems somewhat strange. Is there anything we can do to improve this? Repack? Anything like that? A post about the github system suggests that this is not an isolated problem. http://github.com/blog/92-http-cloning if there is anything we can do to help resolve this issue please let us know. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
