3 ms·

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 improv

by 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.