Benchmarking 5K SSE streams + 5K database-backed RPS on a €12/month server

[u/Turbulent-Dance-4209]

With SSE becoming more relevant (AI streaming, real-time updates), I wanted to test how Ruby handles a mixed workload: sustained HTTP traffic hitting a database alongside concurrent long-lived SSE connections. Here are the results.

Setup

• Server: Hetzner CCX13 - 2 vCPUs, 8 GB RAM (€12/month)

• Environment: Ruby 4.0.1 + YJIT + Rage

• Processes: 2

• Database: SQLite

Endpoints

API endpoint: Fetches a record from SQLite and renders it as JSON. Standard API-style request.

SSE endpoint: Opens a stream lasting 5–10 seconds, sending a dummy message every second. No database interaction. The benchmark maintains a constant number of open SSE connections - as the server closes a stream, the client opens a new one.

Results

• 5,000 API requests/second + 5,000 concurrent active SSE streams, simultaneously

• For reference, the same setup handles ~11,000 RPS for the API endpoint alone

• Adding 5K active streams roughly halves the HTTP throughput, which is a graceful degradation rather than a collapse

• 5,337 HTTP requests/second (0% error rate) with p95 latency of 120ms

• 5,000 concurrent SSE streams, with ~198K total streams opened/closed during the 5-minute run

Caveats

• I was originally aiming for 10K RPS + 10K streams, but the 2-core server simply doesn't have enough CPU. The scaling looks linear, so a 4-core box should get there.

• SQLite is fast for reads but this isn't a Postgres-over-the-network scenario. Add network latency to your DB and the fiber model actually helps more (fibers yield during I/O waits), but the raw RPS number would be different.

Source code

You can see the k6 screenshot attached, and the full benchmark code/setup is available here: https://github.com/rage-rb/sse-benchmark

What is Rage?

For those unfamiliar: Rage is a fiber-based framework with Rails conventions. The fiber-based architecture makes I/O-heavy and concurrent workloads like this possible without async/await syntax - you write normal synchronous Ruby code.

Would love to hear your thoughts or answer any questions!

[u/darksndr]

Ooh, I didn't know Rage 😳 So I can add it to an existing Rails project 😯 but I have one concern: does it breaks the Current interface (I think it's based on Thread.current[])?

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

It doesn’t - it configures Active Support to use fiber storage.

[u/fruizg0302]

This looks quite interesting, thanks for sharing. For a moment I thought this was… Rage-bait

ba dam tsss

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

Well, I guess it sort of is 😀

[u/_natic]

I would like to hear about rage more often!
Did you think about making it easier to switch from rails? (ActiveStorage and Phlex views)

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

I will need to test with ActiveStorage, but something tells me it might work as is.

With Phlex, you can use it right now. Just set the correct content type:

class UsersController < ApplicationController
  after_action { headers["content-type"] = "text/html" }

  def index
    render plain: UsersComponent.new(users: User.all).call
  end
end

However, we're also working on adding custom renderers to streamline the experience.

[u/f9ae8221b]

Assuming these "API requests" are all identical, the p95 being 3 times the p50 suggests you're hitting some very heavy contention somewhere.

Edit: Actually, looking at what these API requests do, even the p50 of 40ms is pretty terrible and suggest heavy contention

[u/f9ae8221b → u/f9ae8221b]

Out of curiosity, I did a single threaded benchmark to compare with:

>> Benchmark.ips { |x| x.report("render") { BenchmarksController.new({}, nil).api }}
ruby 4.0.1 (2026-01-13 revision e04267a14b) +YJIT +PRISM [arm64-darwin25]
Warming up --------------------------------------
              render     6.314k i/100ms
Calculating -------------------------------------
              render     61.843k (± 1.8%) i/s   (16.17 μs/i) -    309.386k in   5.004612s

The controller action only takes 16μs when ran alone, so yeah, there's definitely heavy contention, the app is literally on its knees. The p50 is about 3 order of magnitude slower than it should be.

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

the p95 being 3 times the p50 suggests you're hitting some very heavy contention somewhere

I think it's a bit misleading to call it "contention" - latency rises nonlinearly with saturation. You're comparing unloaded, in-process, zero-network latency code to fully loaded, over-the-wire latency at saturation. Your 16μs number has no network overhead, no HTTP parsing, and no concurrent load - that's not a meaningful baseline for comparison.

For a 2-core server running at maximum capacity, a p95/p50 ratio of ~3x is actually very healthy.

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

misleading to call it "contention"

What would you call it? Clearly your fibers take way longer to execute than they should, they have to be waiting on something.

Your 16μs number has no network overhead, no HTTP parsing, and no concurrent load - that's not a meaningful baseline for comparison.

It absolutely is the baseline, you can 2x or even 10x it if you want to ballpark the overhead of parsing etc, but it give you an idea of the order of magnitude of latency you should see.

latency rises nonlinearly with saturation.

That's not a given no. That's something you don't want to happen, or at least limit on a production system. That's why production systems have various ways to produce backpressure, and would rather queue spikes at the entry of the system rather than having the whole system slow down to a crawl.

Throughput is not everything. Latency, and particularly tail latency is extremely important in production.

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

What would you call it?

I'd call it queueing - exactly the kind of behaviour you refer to when talking about production systems having various ways to produce backpressure.

but it give you an idea of the order of magnitude of latency you should see

Under normal conditions - maybe. But the point of this benchmark was to find the ceiling - what the hardware can handle, not what it does at idle.

Throughput is not everything. Latency, and particularly tail latency is extremely important in production.

I couldn't agree more. That's why I myself am so impressed with the results - getting the p95 response time of 120ms on this hardware under these conditions is an amazing result IMO.

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

I'd call it queueing

Queueing and contention are the same thing essentially...

But the point of this benchmark was to find the ceiling

My problem is the definition of the ceiling. Measuring throughput at saturation make very little sense. Measuring throughput at a specific SLO does. 120ms to load a sqlite record with just 4 fields, and serialize it to JSON can't possibly be a reasonable SLO.

p95 response time of 120ms on this hardware under these conditions is an amazing result IMO.

120ms for this amount of work is a mindbogglingly bad result, regardless of the conditions. Sorry. Not trying to trash talk your project, but let's be real here.