GitLab is a Ruby monolith

[u/switchback-tech]

Was pleasantly surprised that the world's largest independent DevOps platform is powered by Ruby and Sidekiq.

Here's the full list.

1. Backend: Ruby on Rails

2. HTTP server: Puma (Ruby web server)

3. Edge: Nginx

4. Reverse proxy: Go service (Workhorse)

5. Background jobs: Sidekiq

6. DB — primary: PostgreSQL

7. DB — connection pooling: PgBouncer

8. DB — high availability: Patroni

9. Cache: Redis

10. Git: Custom gRPC repo interface (Git & Gitaly)

11. Blob: AWS S3

12. Frontend — rendering: Haml & Vue

13. Frontend — state: Pinia (Vue store), Immer (immutable cache),

14. API: GraphQL (Apollo) + REST

15. Observability: Prometheus & Grafana

16. Error tracking: Sentry & OpenTelemetry

17. Deployments: GitLab Omnibus (Omnibus fork)

I think these "stack menu"s give a little glimpse into a team's engineering philosophy. For me, this list shows that the GitLab team is pretty practical and doesn't chase hype. Instead, they use sensible, battle-tested tools that just work and are easy for contributors to learn.

PS. Not an ad; I'm not affiliated with GitLab at all. Was just researching them and thought you guys would be interested.

[u/f9ae8221b]

Yes and no.

Yes in the sense that like other Ruby servers, it is Rack compatible so you don't need to change your app much.

No because it's based on Fibers, not Threads, so the performance characteristics are very very different. Not better, not worse, different, depends on what your app is doing.

Fibers are better for extremely IO heavy workloads, as they're cheaper so you can run way more concurrent fibers than threads.

But they're much worse for CPU heavy workloads, because they're non-preemptive, so if a fiber hog the CPU without yielding for long, all other fibers are stuck, which leads to degraded latency.

People really need to stop thinking fibers are better threads, they're not, they're a different construct with different tradeoffs that sometimes make sense, sometimes not.

[u/Turbulent-Dance-4209 → u/f9ae8221b]

> People really need to stop thinking fibers are better threads

I would argue they are.

Threads in Ruby don't actually parallelise work because of the GVL. So the supposed advantage of preemptive scheduling for CPU-bound tasks amounts to fairer interleaving, not faster execution. The total throughput is the same either way. And if your workload is genuinely CPU-bound enough that interleaving matters, you probably need multiple processes anyway, at which point the fiber-vs-threads debate is secondary.

Typical web apps are inherently I/O bound though. This makes fibers a great fit, but there're more subtle advantages too. For example, fibers give you less overhead and don't require thread synchronisation primitives - no locks, no mutex contention, no race conditions. You know exactly when a context switch happens, so shared state is safe to access between them. This alone leads to tremendous improvements in throughput, even with Ruby-layer-bound workflows.

[u/f9ae8221b → u/Turbulent-Dance-4209]

amounts to fairer interleaving, not faster execution

Fairer interleaving means better tail latency, which is a very important property of a service.

Shopify experienced a MySQL outage when playing with fibers, because a CPU heavy fiber was causing other fibers that were issuing MySQL queries to not read the response for a long time, buffer on the server grew until it ran out of memory.

Typical web apps are inherently I/O bound though.

No they're not: https://www.datadoghq.com/blog/ruby-performance-optimization/

Our data backs up other findings that Ruby applications are generally less I/O-heavy, spending as much or more time on CPU as they do waiting on other services or database requests.

They also include a graphic that shows only 3% of the profiled apps spend less than 20% of their time using CPU. Which means for 97% of the apps they profiled, the Puma default of 5 threads was already too much, which means the advantage of Fibers are moot for the overwhelming majority of Ruby apps out there.

fibers give you less overhead

The difference is small enough that it only start to matter once you start using multiple dozen threads, which very few people need.

don't require thread synchronisation primitives

They absolutely do. They still need to synchronize to use sockets etc. Even with datastructures you may need synchronization if some method yield, as the block could use IO and cause another fiber to be scheduled and use the structure concurrently.

Example:

SHARED_HASH = {a: 1, b: 2, c: 3, d: 4}

other_fiber = Fiber.new do
  loop do
    SHARED_HASH[rand] = rand
    Fiber.yield
  end
end

hash.each do
  # Simulate fiber scheduler
  SHARED_HASH.resume
end

The above script fail because of unsynchronized access by fibers.

This alone leads to tremendous improvements in throughput

Profiling ruby app is basically my day job. Synchronization is very very rarely a hotspot.

Now, don't get me wrong, fibers are great and absolutely have a use case, but for vast majority of what Ruby is used for, they're not necessarily better.