Maybe this is a case where ruby is just not the right tool, how does github does it?

honest questions:

Is performance not that important for gitlab cause your revenue comes from self-hosted, where performance might be less of an issue because of lower load? Isn't gitlab highly concerned with a new company starting a similar product in a more efficient language implementation and eating your lunch?

apologize if these questions sound a bit harsh, gitlab is doing great work and lots of users enjoy your product, I guess these is one of the perks for exposing yourself too much to the community ;)

This is not due to Ruby, both we and GitHub use that. We do offload some tasks to Go processes with GitLab workhorse to take advantage of multithreading. But therr are a few reasons GitLab.com is slow:

1. I didn't prioritize growing our infrastructure team after raising our A round, for a long time it was one person running GitLab.com. In the last couple of months I realized my error and now we're about 8 people and hiring.

2. We're shipping a lot of new features every month and we where not monitoring for performance regressions. We have better monitoring in place now.

3. GitLab.com runs on one file server. This release adds the capability to add multiple ones. We are also testing Ceph to make it completely distributed.

4. Some problems only occur at scale. GitLab.com is running GitLab Enterprise Edition with more than 500k accounts created. This causes problems that don't occur at 10k users.

5. Our monitoring infrastructure has been coarse. We're now using Prometheus to improve this.

> Isn't gitlab highly concerned with a new company starting a similar product in a more efficient language implementation and eating your lunch?

I'm nobody but my two cents is that this falls under the category of things we shouldn't worry about because there isn't much we can do about it. I am sure Gitlab is concerned but I would say it doesn't matter because this is a problem you can probably throw hardware at (repo A going down will likely not affect most repo B users). I imagine of course gitlab.com would want to make the most of the hardware it has and I'd love to read about the cost of porting gitlab to a "more efficient" language implementation but I hope they're more concerned about delivering value to users than worrying about how to fend off competition.

This might be unpopular here but I hope Gitlab does all it can to keep their cost low even if it means slightly lower salaries.