3 ms·

Was over a year since I last used GitLab, and I wonder if the resource usage and response times of a self-hosted instance has improved? Back then we were 3 deve

Was over a year since I last used GitLab, and I wonder if the resource usage and response times of a self-hosted instance has improved? Back then we were 3 developers having roughly 20 repos. The memory usage was over 2GB when idle and response times were at best between 2-3 seconds. Testing your hosted version, loading this page[1] for example takes 4 seconds (3.6s TTFB). Don't get me wrong, the platform and its features are very broad and very good, but I personally can't stand having such long loading times. It's very frustrating because I really want to use GitLab and its features. My feedback would be to set a main focus on reducing the TTFB for the Web UI, but also the Git server, because it takes a couple of seconds for it to respond to pushes. [1] https://gitlab.com/gitlab-org/gitlab-ce/commits/master https://gitlab.com/gitlab-org/gitlab-ce/commits/master

alexwebb2 10y ago
They've done a lot of work on performance in the past year. I'd recommend taking it for another spin.
- nilved 10y ago
  Not enough, apparently. That page takes 10.5s to load and fails several performance metrics. https://tools.pingdom.com/#!/cOKg2F/https://gitlab.com/gitlab-org/gitlab-ce/commits/master https://tools.pingdom.com/#!/cOKg2F/https://gitlab.com/gitla...
  - jobvandervoort 10y ago
    See my comment above, but in short: GitLab.com is not representative of a self-hosted GitLab instance. GitLab.com is too slow. We're working on it here: https://gitlab.com/gitlab-com/infrastructure/issues/59 https://gitlab.com/gitlab-com/infrastructure/issues/59
  - connorshea 10y ago
    I get 5.5s now when I re-run it (probably due to caching). We've been working incredibly hard to make it faster, we have to use it everyday, so we know exactly how annoying the lack of speed can be. For example, take a look at the drop in response time in the middle of last month: http://stats.pingdom.com/81vpf8jyr1h9/1902794/2016/07 http://stats.pingdom.com/81vpf8jyr1h9/1902794/2016/07 We've focused on speeding up some more common pages (Issues, MRs, etc.), but still a ways to go for the rest of the application! Ceph should make a big difference once we get GitLab.com running on it in a few months, the reason the commits page specifically is so slow is because our current infrastructure is bottlenecked by filesystem-heavy interactions (e.g. getting all the recent git commits for a repository). Ceph issues are here: https://gitlab.com/gitlab-com/infrastructure/issues?scope=all&sort=updated_desc&state=opened&utf8=%E2%9C%93&label_name%5B%5D=ceph&label-name= https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...
jobvandervoort 10y ago
If you run your own instance of GitLab now, it will be fast. Since last year March we've grown from 9 to now 100 people, many of which dedicated to performance. GitLab.com is slow, occasionally painfully so. We're very aware of that and are working to improve that. You're welcome to watch or contribute here [0]. [0]: https://gitlab.com/gitlab-com/infrastructure/issues/59 https://gitlab.com/gitlab-com/infrastructure/issues/59
- deleted 10y ago
  [deleted]

alexwebb2 10y ago

They've done a lot of work on performance in the past year. I'd recommend taking it for another spin.

nilved 10y ago
Not enough, apparently. That page takes 10.5s to load and fails several performance metrics. https://tools.pingdom.com/#!/cOKg2F/https://gitlab.com/gitlab-org/gitlab-ce/commits/master https://tools.pingdom.com/#!/cOKg2F/https://gitlab.com/gitla...
- jobvandervoort 10y ago
  See my comment above, but in short: GitLab.com is not representative of a self-hosted GitLab instance. GitLab.com is too slow. We're working on it here: https://gitlab.com/gitlab-com/infrastructure/issues/59 https://gitlab.com/gitlab-com/infrastructure/issues/59
- connorshea 10y ago
  I get 5.5s now when I re-run it (probably due to caching). We've been working incredibly hard to make it faster, we have to use it everyday, so we know exactly how annoying the lack of speed can be. For example, take a look at the drop in response time in the middle of last month: http://stats.pingdom.com/81vpf8jyr1h9/1902794/2016/07 http://stats.pingdom.com/81vpf8jyr1h9/1902794/2016/07 We've focused on speeding up some more common pages (Issues, MRs, etc.), but still a ways to go for the rest of the application! Ceph should make a big difference once we get GitLab.com running on it in a few months, the reason the commits page specifically is so slow is because our current infrastructure is bottlenecked by filesystem-heavy interactions (e.g. getting all the recent git commits for a repository). Ceph issues are here: https://gitlab.com/gitlab-com/infrastructure/issues?scope=all&sort=updated_desc&state=opened&utf8=%E2%9C%93&label_name%5B%5D=ceph&label-name= https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...

jobvandervoort 10y ago

If you run your own instance of GitLab now, it will be fast. Since last year March we've grown from 9 to now 100 people, many of which dedicated to performance. GitLab.com is slow, occasionally painfully so. We're very aware of that and are working to improve that. You're welcome to watch or contribute here [0]. [0]: https://gitlab.com/gitlab-com/infrastructure/issues/59 https://gitlab.com/gitlab-com/infrastructure/issues/59

deleted 10y ago
[deleted]