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.
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.
> 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.
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-...
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`.
We hope to make improvements in this area soon. Hopefully you'll notice them!