[sinaa]

Really happy for GitLab and wish you guys all the best (and luck).

We've been using Gitlab for all our company's development, however, one major issue that is pushing us to switch over to GitHub is the fact that GitLab goes down almost every other day (or sometimes every day) due to deployments. Although during this often the site remains available, when CI is not executed or triggers are not performed, it is still extremely disruptive. I really hope that you prioritise having disruption-free deployments.

[sytse]

Thanks for your comment. Self hosted GitLab has been very reliable but GitLab.com's availability has been far below par.

It is our nr. 1 focus to improve this. Deployments should not cause disruptions. Over the last few months we solved the speed of GitLab.com. Availability is next.

[lucideer]

Firstly, I'm really happy to see Gitlab growing and desperately want to see it succeed. We need an open-source alternative, and the organisational transparency within the company is also wonderful. However...

> we solved the speed of GitLab.com

I'm currently browsing a repo tree and each page is taking 5+ seconds to load (I am literally browsing HN while waiting for pages to open). This is a common experience. Please please don't get complacent. Not yet.

[suprememoocow]

I'm the Gitaly Lead at GitLab. Gitaly is a GitLab project to move all the git operations out of the GitLab Ruby monolith into a Git RPC service.

https://gitlab.com/gitlab-org/gitaly/

We're hoping to complete this by the end of the year. Once it's done, we'll be able to end our reliance on NFS, which should greatly improve performance and uptime on GitLab.com and other large GitLab instances. In fact, we're already seeing some big performance payoffs as we bring services online.

> Please please don't get complacent. Not yet.

I can confirm that this is not the case. We're focused and working really hard to improve performance and we're also working hard to improve our metrics, so that we can target optimizations where we can gain greatest benefit.

It's also worth pointing out that routinely experiencing 5+ second render times on browsing a repo homepage is outside our 99th percentile latencies for that route. I'd be interesting in digging into it further. Would you mind creating an issue in https://gitlab.com/gitlab-org/gitaly/issues/new (mark it as confidential if you wish) and ping me `@andrewn`.

[lucideer]

The 5+ second delay is a little above the average (I'm rarely frustrated enough to actually go off and get distracted by HN while I wait), but notable delays on loading repo trees are definitely common, if not usually quite so high.

[suprememoocow]

Repo tree rendering is a known issue that we're currently looking into: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14680

We hope to make improvements in this area soon. Hopefully you'll notice them!

[sytse]

Thanks, I wanted to indicate our primary focus moved from the speed to the availability. But you're very right that there is still much to improve. We're not happy until every page is fast.

Specifically about the repo tree page load:

1. I'll share this comment with our VP of Eng

2. We're working on Gitaly to make git calls faster.

3. We're working on a multifile editor to make browsing faster.

BTW Here is a graph of how some of the other pages improved https://www.dropbox.com/s/8ztha1av8t0fcau/Screenshot%202017-...

[lucideer]

Thanks. Good feedback to hear.