5 ms·

I'm not aware of the performance bottlenecks with GitLab, but are there any plans to speed up the backend as well, such as moving to a faster Ruby implementatio

I'm not aware of the performance bottlenecks with GitLab, but are there any plans to speed up the backend as well, such as moving to a faster Ruby implementation?

jabl 10y ago
There's another github/gitlab clone called gigs that's implemented in go. Never used it myself, but if you want to save server resources I guess it's an option.
- gtaylor 10y ago
  *Gogs
  - jabl 10y ago
    Thank you, indeed it's gogs ( https://gogs.io/ https://gogs.io/ ) Damn you autocorrect!
- pythonaut_16 10y ago
  Interestingly enough, Gitlab also supports that project: https://about.gitlab.com/gogs/ https://about.gitlab.com/gogs/
- connorshea 10y ago
  It should be noted that Gogs was recently forked to Gitea due to disagreements about the management style of Gogs as an open source project. See https://blog.gitea.io/2016/12/welcome-to-gitea/ https://blog.gitea.io/2016/12/welcome-to-gitea/
chrisseaton 10y ago
Yes actually I think they had one developer working part time on Rubinius.
cmatija 10y ago
Definitely. We have lots of ongoing efforts. (Not necessarily moving to a different Ruby implementation, though) You can take a look at an overview of our efforts here: https://gitlab.com/gitlab-com/infrastructure/issues/947 https://gitlab.com/gitlab-com/infrastructure/issues/947
- jeffbachtel 10y ago
  Does GitLab have any plans to implement a git server that does not rely on POSIX filesystem semantics and gets away from the need for NFS? It seems like a git server storing objects in an object store would allow the GitLab SaaS to scale out better.
  - northrup 10y ago
    GitLab does have a plan to try and mitigate the bulk of pain generated from hosting lots of git repositories against a POSIX based filesystem by abstracting a layer of caching functionality and horizontal scaling. This project is called Gitaly[0] and is being tracked on GitLab.com [0] https://gitlab.com/gitlab-org/gitaly https://gitlab.com/gitlab-org/gitaly
YorickPeterse 10y ago
We have no plans to move to another Ruby implementation, primarily because Ruby itself is not yet a bottleneck for us.
- ZenoArrow 10y ago
  Is it something you'd consider? Even if it's not a performance bottleneck right now it's probably worth it to reduce server costs (more efficient Ruby implementation = fewer servers required to run GitLab.com). Could be looking at serious gains, 3x over CRuby looks to be a fairly reasonable goal when using RubyTruffle (slow startup times can be mitigated against with SubstrateVM), and if that's not an option due to it being a fairly new project, it seems like JRuby could give a decent performance boost too. https://pragtob.wordpress.com/2015/11/30/benchmarking-a-go-ai-in-ruby-cruby-vs-rubinius-vs-jruby-vs-trufflegraal/ https://pragtob.wordpress.com/2015/11/30/benchmarking-a-go-a... https://m.youtube.com/watch?v=wwEVakQzVAw https://m.youtube.com/watch?v=wwEVakQzVAw
  - connorshea 10y ago
    JRuby isn't an option for us because we use too many gems, many of which have compatibility issues with JRuby's implementation of Ruby. This is especially a problem for gems with C extensions. I think Truffle is the most interesting new development in this realm, if it gets support for C extensions as they plan for it to, it may eventually be reasonable to run GitLab on it. That wouldn't be for a few more years though.
  - YorickPeterse 10y ago
    There is no such thing as: 1. Replace Ruby implementation 2. ??? 3. Everything is 3x faster Whatever an implementation or product claims, it's just not possible. While we could benefit from not having a GIL (something Truffle has if I'm not mistaken), it's not a free trade-off. For example: * JRuby typically requires quite a bit more memory compared to CRuby, the same probably applies to Truffle * Dependencies might have to be replaced if they're written in C. I personally don't buy Truffle being able to support all extensions. It's super fucking hard. I spent a few years working on Rubinius and had the unfortunate experience of having to deal with C extensions a lot. Supporting these properly is really, really difficult. * JRuby might not work on all platforms we support. For example, we support Raspberry Pi's and the likes and it's not clear if JRuby would work there Most importantly of all: a large portion of our slowness is due to badly written SQL queries, code that hammers the database way too often, and our Git operations. None of this would be solved by switching to a different Ruby implementation. The only way to solve this is to: 1. Solve the code 2. Educate developers so they don't make the same mistakes 3. Add linting rules and the likes so our CI environment catches any mistakes (where possible)

I'm not aware of the performance bottlenecks with GitLab, but are there any plans to speed up the backend as well, such as moving to a faster Ruby implementation?

jabl 10y ago

There's another github/gitlab clone called gigs that's implemented in go. Never used it myself, but if you want to save server resources I guess it's an option.

gtaylor 10y ago
*Gogs
- jabl 10y ago
  Thank you, indeed it's gogs ( https://gogs.io/ https://gogs.io/ ) Damn you autocorrect!
pythonaut_16 10y ago
Interestingly enough, Gitlab also supports that project: https://about.gitlab.com/gogs/ https://about.gitlab.com/gogs/
connorshea 10y ago
It should be noted that Gogs was recently forked to Gitea due to disagreements about the management style of Gogs as an open source project. See https://blog.gitea.io/2016/12/welcome-to-gitea/ https://blog.gitea.io/2016/12/welcome-to-gitea/

chrisseaton 10y ago

Yes actually I think they had one developer working part time on Rubinius.

cmatija 10y ago

Definitely. We have lots of ongoing efforts. (Not necessarily moving to a different Ruby implementation, though) You can take a look at an overview of our efforts here: https://gitlab.com/gitlab-com/infrastructure/issues/947 https://gitlab.com/gitlab-com/infrastructure/issues/947

jeffbachtel 10y ago
Does GitLab have any plans to implement a git server that does not rely on POSIX filesystem semantics and gets away from the need for NFS? It seems like a git server storing objects in an object store would allow the GitLab SaaS to scale out better.
- northrup 10y ago
  GitLab does have a plan to try and mitigate the bulk of pain generated from hosting lots of git repositories against a POSIX based filesystem by abstracting a layer of caching functionality and horizontal scaling. This project is called Gitaly[0] and is being tracked on GitLab.com [0] https://gitlab.com/gitlab-org/gitaly https://gitlab.com/gitlab-org/gitaly

YorickPeterse 10y ago

We have no plans to move to another Ruby implementation, primarily because Ruby itself is not yet a bottleneck for us.

ZenoArrow 10y ago
Is it something you'd consider? Even if it's not a performance bottleneck right now it's probably worth it to reduce server costs (more efficient Ruby implementation = fewer servers required to run GitLab.com). Could be looking at serious gains, 3x over CRuby looks to be a fairly reasonable goal when using RubyTruffle (slow startup times can be mitigated against with SubstrateVM), and if that's not an option due to it being a fairly new project, it seems like JRuby could give a decent performance boost too. https://pragtob.wordpress.com/2015/11/30/benchmarking-a-go-ai-in-ruby-cruby-vs-rubinius-vs-jruby-vs-trufflegraal/ https://pragtob.wordpress.com/2015/11/30/benchmarking-a-go-a... https://m.youtube.com/watch?v=wwEVakQzVAw https://m.youtube.com/watch?v=wwEVakQzVAw
- connorshea 10y ago
  JRuby isn't an option for us because we use too many gems, many of which have compatibility issues with JRuby's implementation of Ruby. This is especially a problem for gems with C extensions. I think Truffle is the most interesting new development in this realm, if it gets support for C extensions as they plan for it to, it may eventually be reasonable to run GitLab on it. That wouldn't be for a few more years though.
- YorickPeterse 10y ago
  There is no such thing as: 1. Replace Ruby implementation 2. ??? 3. Everything is 3x faster Whatever an implementation or product claims, it's just not possible. While we could benefit from not having a GIL (something Truffle has if I'm not mistaken), it's not a free trade-off. For example: * JRuby typically requires quite a bit more memory compared to CRuby, the same probably applies to Truffle * Dependencies might have to be replaced if they're written in C. I personally don't buy Truffle being able to support all extensions. It's super fucking hard. I spent a few years working on Rubinius and had the unfortunate experience of having to deal with C extensions a lot. Supporting these properly is really, really difficult. * JRuby might not work on all platforms we support. For example, we support Raspberry Pi's and the likes and it's not clear if JRuby would work there Most importantly of all: a large portion of our slowness is due to badly written SQL queries, code that hammers the database way too often, and our Git operations. None of this would be solved by switching to a different Ruby implementation. The only way to solve this is to: 1. Solve the code 2. Educate developers so they don't make the same mistakes 3. Add linting rules and the likes so our CI environment catches any mistakes (where possible)