5 ms·

Same here. Gitlab is soooo extremely slow. Even on their own site many pages take several seconds to load. And no one really seems to care. Gogs is a great rel

by mh-cx 11y ago

Same here. Gitlab is soooo extremely slow. Even on their own site many pages take several seconds to load. And no one really seems to care. Gogs is a great relief.

sytse 11y ago
GitLab.com is slow because of operational issues, like everything running from one NFS server. GitLab on your own server with enough memory should be fast. The slowness of GitLab.com is unacceptable to us, work to improve it is ongoing in https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42
- 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.
- matheweis 11y ago
  Properly tuned NFS should be extremely fast... I've managed NFS clusters for HPC that exceeded 800Mbit/s and 20k IOPS
  - sytse 11y ago
    The problem is that we should distribute the load over multiple servers https://gitlab.com/gitlab-com/operations/issues/1 https://gitlab.com/gitlab-com/operations/issues/1 Right now the lonely repository server has over 200k context switches per second.
    - matheweis 11y ago
      Your engineers probably know this, but CephFS is not well known for handing high IOPS loads; make sure to architect accordingly :)
      - sytse 11y ago
        Thanks for the advice, do you maybe have a link with more details?
        matheweis 11y ago
        Mirantis gave a talk last year at OpenStack with real-world numbers... They had to scale to 500 storage nodes to achieve 50k IOPS aggregate. https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/building-your-first-ceph-cluster-for-openstack-fighting-for-performance-solving-tradeoffs https://www.openstack.org/summit/vancouver-2015/summit-video... https://www.slideshare.net/mobile/mirantis/ceph-talk-vancouver-20 https://www.slideshare.net/mobile/mirantis/ceph-talk-vancouv...
        sytse 11y ago
        Wow, thanks for those numbers and the links, I've added them to https://gitlab.com/gitlab-com/operations/issues/1#note_4483625 https://gitlab.com/gitlab-com/operations/issues/1#note_44836...
- frik 11y ago
  Are you still on Azure or have you moved on? You had several blog/twitter posts about how unreliable Azure is and documented some quirks like failed reboots. But arguable you got Azure cloud for free. Don't look a gift horse in the mouth. But what's worse? I read about the problems since November 2015. Maybe invest in Google/AWS cloud and don't run it on a single NFS.
  - sytse 11y ago
    We're still on Azure. We got a lot of help from Microsoft to work out the things we encountered. They have been very helpful and we plan to stay on Azure for now. Getting rid of the single NFS server is our next step.
xyproto 11y ago
Tried both Gogs and Gitlab at work. Gogs is faster, but Gitlab has most features and the best chance of being introduced. Also, we are happily using Mattermost, which is created by the same people. Gollum also looks like a solid choice of Wiki. Also note that the latest version of GitLab is a lot faster than it used to be.
- sytse 11y ago
  Glad to hear our focus on improving speed is paying off, we'll continue it in https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42

by mh-cx 11y ago

Same here. Gitlab is soooo extremely slow. Even on their own site many pages take several seconds to load. And no one really seems to care. Gogs is a great relief.

sytse 11y ago

GitLab.com is slow because of operational issues, like everything running from one NFS server. GitLab on your own server with enough memory should be fast. The slowness of GitLab.com is unacceptable to us, work to improve it is ongoing in https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42

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.
matheweis 11y ago
Properly tuned NFS should be extremely fast... I've managed NFS clusters for HPC that exceeded 800Mbit/s and 20k IOPS
- sytse 11y ago
  The problem is that we should distribute the load over multiple servers https://gitlab.com/gitlab-com/operations/issues/1 https://gitlab.com/gitlab-com/operations/issues/1 Right now the lonely repository server has over 200k context switches per second.
  - matheweis 11y ago
    Your engineers probably know this, but CephFS is not well known for handing high IOPS loads; make sure to architect accordingly :)
    - sytse 11y ago
      Thanks for the advice, do you maybe have a link with more details?
      - matheweis 11y ago
        Mirantis gave a talk last year at OpenStack with real-world numbers... They had to scale to 500 storage nodes to achieve 50k IOPS aggregate. https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/building-your-first-ceph-cluster-for-openstack-fighting-for-performance-solving-tradeoffs https://www.openstack.org/summit/vancouver-2015/summit-video... https://www.slideshare.net/mobile/mirantis/ceph-talk-vancouver-20 https://www.slideshare.net/mobile/mirantis/ceph-talk-vancouv...
        sytse 11y ago
        Wow, thanks for those numbers and the links, I've added them to https://gitlab.com/gitlab-com/operations/issues/1#note_4483625 https://gitlab.com/gitlab-com/operations/issues/1#note_44836...
frik 11y ago
Are you still on Azure or have you moved on? You had several blog/twitter posts about how unreliable Azure is and documented some quirks like failed reboots. But arguable you got Azure cloud for free. Don't look a gift horse in the mouth. But what's worse? I read about the problems since November 2015. Maybe invest in Google/AWS cloud and don't run it on a single NFS.
- sytse 11y ago
  We're still on Azure. We got a lot of help from Microsoft to work out the things we encountered. They have been very helpful and we plan to stay on Azure for now. Getting rid of the single NFS server is our next step.

xyproto 11y ago

Tried both Gogs and Gitlab at work. Gogs is faster, but Gitlab has most features and the best chance of being introduced. Also, we are happily using Mattermost, which is created by the same people. Gollum also looks like a solid choice of Wiki. Also note that the latest version of GitLab is a lot faster than it used to be.

sytse 11y ago
Glad to hear our focus on improving speed is paying off, we'll continue it in https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42