4 ms·
They've done a lot of work on performance in the past year. I'd recommend taking it for another spin.
by 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 agoNot 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 agoSee 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 agoI 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...