Thanks for the post Konstantin.
There won't be many concurrent users (say 10) hence not many cloning at the 
same time.
My main requirement was using git as some type of storage space with 
versioning capability.

On Monday, April 4, 2016 at 4:18:17 PM UTC-4, Konstantin Khomoutov wrote:
> On Mon, 4 Apr 2016 12:59:38 -0700 (PDT) 
> display_name_taken < <javascript:>> wrote: 
> > I'm trying to find out what is the maximum number of repositories a 
> > given git server can handle or is there such a limit? 
> > For example can git server works without any issues if there are 1000 
> > repositories? 
> > Each repository will have only few files (10 or less) and the size of 
> > each repository will be few megabytes. 
> You maintain a wrong mental model about Git. 
> When you access a Git repository hosted on a server you either talk to 
> an SSH server or an HTTP server or the so-called Git daemon directly 
> (when a repository is being accessed using the URL beginning with 
> git://), but in either case, to access that repository a separate OS 
> process is started -- running one of the special low-level Git tools. 
> Hence *if* you're in the end using Git to serve your repositories, the 
> server's capaticy is more about handling the desired number of 
> simultaneously run processes each potentially using a hefty amount of 
> memory (big fetches for instance).  Disk throughput might also 
> potentially become a bottleneck. 
> On the other hand, here we're talking about concurrent access. 
> I'm pretty sure that to really have 1000 clients concurrently cloning 
> big repositories, you'd have to have some x100 as much repositories 
> because IMO having such "thundering herd" spikes, when all the clients 
> potential clients all of a sudden start cloning their repositories is 
> pretty much unlikely -- unless you're being DOSed. 
> In either case, what's the point in such "guesseneering"? 
> Have a test server and simulate the desired workload. 
> If you're about hosting that much repositories you should not be 
> pulling the sample data out of anectotes heard on some public forums. 
> Oh, and while we're at it: the model I outlined -- one specialized Git 
> process serving a single client accessing a single repository -- is, 
> again, when you're using plain vanilla Git for serving (plus some 
> front-end may be, such as SSH or HTTP server).  If you're using a 
> solution which does not use plain Git (such as Gitblit), the situation 
> may be very different. 

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to