4 ms·

Can't confirm that. I have to work with gitlab with different customers on several independent project teams. No installation feels fast. Memory is >2GB. Also h

by mh-cx 11y ago

Can't confirm that. I have to work with gitlab with different customers on several independent project teams. No installation feels fast. Memory is >2GB. Also have it here on a machine with 4GB. No page loads under 1 s. And the ajax requests seem to take even longer than a full page reload. Its a pitty you now load almost everything with Ajax and there's no option to turn that off. I often find myself to click a second time on a link because the browser spinner doesn't move and your progress bar is not really where my focus is. I had been using 5.1 for quite some time before. It wasn't really fast either, but things have gotten much worse with newer versions.

sytse 11y ago
Thanks for your feedback. As we added more and more functionality to GitLab it probably has gotten slower. Since a few months we have 2 people working on improving performance fulltime. As you can see in https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42 our focus is GitLab.com performance but many of the changes should also improve the speed for on-premises installations. Changes include fewer calls to git, better caching of markdown rendering, etc. We already saw a lot of improvement in GitLab 8.5 https://about.gitlab.com/2016/02/22/gitlab-8-5-released/ https://about.gitlab.com/2016/02/22/gitlab-8-5-released/ and we plan to continue making progress here.
- mh-cx 11y ago
  Sounds good. But honestly since I've read this my faith in the ruby/rails stack (or is it the gitlab devs?) is somewhat limited: http://doc.gitlab.com/ce/operations/sidekiq_memory_killer.html http://doc.gitlab.com/ce/operations/sidekiq_memory_killer.ht... A quite forthright confession of memory leaks - with imo questionable countermeasures.
  - sytse 11y ago
    Blame us more than the stack. These memory leaks are hard to diagnose. Our meta issue to do this is https://gitlab.com/gitlab-org/gitlab-ce/issues/3700 https://gitlab.com/gitlab-org/gitlab-ce/issues/3700 We're currently we're more focussed on improving responsiveness and plan to address the memory leaks and a multithreaded app server https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 after that.

by mh-cx 11y ago

sytse 11y ago

Thanks for your feedback. As we added more and more functionality to GitLab it probably has gotten slower. Since a few months we have 2 people working on improving performance fulltime. As you can see in https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42 our focus is GitLab.com performance but many of the changes should also improve the speed for on-premises installations. Changes include fewer calls to git, better caching of markdown rendering, etc. We already saw a lot of improvement in GitLab 8.5 https://about.gitlab.com/2016/02/22/gitlab-8-5-released/ https://about.gitlab.com/2016/02/22/gitlab-8-5-released/ and we plan to continue making progress here.

mh-cx 11y ago
Sounds good. But honestly since I've read this my faith in the ruby/rails stack (or is it the gitlab devs?) is somewhat limited: http://doc.gitlab.com/ce/operations/sidekiq_memory_killer.html http://doc.gitlab.com/ce/operations/sidekiq_memory_killer.ht... A quite forthright confession of memory leaks - with imo questionable countermeasures.
- sytse 11y ago
  Blame us more than the stack. These memory leaks are hard to diagnose. Our meta issue to do this is https://gitlab.com/gitlab-org/gitlab-ce/issues/3700 https://gitlab.com/gitlab-org/gitlab-ce/issues/3700 We're currently we're more focussed on improving responsiveness and plan to address the memory leaks and a multithreaded app server https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 after that.