Ideas for getting rid of gitaly-ruby
Gitaly-ruby is a sidecar process used by Gitaly to handle requests with code that was originally part of gitlab-ce/ee. There are questions going around regarding whether we can eliminate this sidecar process in order to reduce our memory footprint. In this issue we will reflect on whether that is possible and what that would take.
My starting assumption is that we don't want to make a new sidecar in Go (instead of Ruby). My impression is that sidecars that live longer than 1 request get bloated over time. We would not be better off than we are now with gitaly-ruby.
There are roughly 3 types of RPC's in gitaly-ruby:
- RPC's that make no essential use of Rugged
- RPC's that make essential use of Rugged (creating merge commits, merge conflict resolution, etc.)
- Wiki RPC's
These categories are ordered in ascending difficulty of re-implementing outside gitaly-ruby.
The first category carries risk of accidental behavior changes, because it means we would re-write Ruby implementations in Go. Otherwise they are doable.
The second category I would try to approach by creating one-shot ruby executables that perform one request only. This will add latency compared to how gitaly-ruby performs now (up to 1s to load rugged) but I am hoping we can get away with it. If we can't we can look into using one-shot Go+git2go executables. Git2go is the Go version of Rugged. Rewriting an RPC implementation from Ruby+Rugged to Go+Git2go carries risk of behavior changes but it should at least be possible. Note that there would be a one time cost of integrating Git2go which is not trivial (it would be our first Cgo dependency).
The third category is special because our Wiki RPC's lean on gollum-lib, a third-party library. The act of just loading this library (require 'gollum-lib') adds 3 seconds to process startup time so I am disinclined to take the "one-shot ruby process" approach here. Because it's a library it would also be harder to rewrite it in Go+Git2go. There is another path we could take (thanks @zj), namely to move gollum-lib back from gitaly-ruby to gitlab-ce, and to write an adapter that allows Gollum to query Gitaly. Performance might suffer due to N+1 queries originating in gollum-lib but it would probably still be better than a fixed 3s RPC overhead.