Hacker News Reader

Comment by ZenoArrow | Hacker News Reader

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?

View on HN

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

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.

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

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.

*Gogs

Thank you, indeed it's gogs ( https://gogs.io/ )

Damn you autocorrect!

Interestingly enough, Gitlab also supports that project:

https://about.gitlab.com/gogs/

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/

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

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

https://m.youtube.com/watch?v=wwEVakQzVAw

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.

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)

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

Reply on news.ycombinator.com