The Weight of Your Web Stack, Part 2: What Your Backend Costs Under Load

In Part 1, we measured what web backend frameworks cost before serving a single request — idle memory, startup time, and Docker image sizes. We found a 30-100x spread between the lightest (Rust at 3 MB) and heaviest (Spring Boot at 500 MB) frameworks. In Part 3 we cover how to actually choose the right backend for your workload, team, and scale.

But idle cost is only half the story. Some frameworks with high startup costs become remarkably efficient once they’re running. Others with tiny idle footprints hit scaling walls under load. The question every developer and architect needs answered is: after your application is warmed up and running, how does each language actually perform?

We compiled data from TechEmpower Rounds 22 and 23, the Sharkbench Web Framework Benchmark (August 2025), and 40+ independent benchmark studies to find out.

Warmed-Up Throughput: The Steady-State Rankings

First, the raw numbers. This table shows throughput after warmup, measured on the same hardware (Sharkbench: Ryzen 7 7800X3D, Docker, 1 CPU core equivalent) running concurrent HTTP requests with JSON serialization and I/O operations.

* Stability = median latency / P99 latency ratio. Higher means more predictable response times.

Source: Sharkbench Web Framework Benchmark, August 2025

Several things jump out of this data.

Java Vert.x tops the chart — not Rust. At 23,116 req/s, Java’s reactive framework actually beats Rust Actix (21,965 req/s) on this benchmark. But it does so at a cost of 484 MB of memory, a 29x memory penalty compared to Rust Axum’s 8.5 MB for similar throughput.

Go looks surprisingly slow at 3,546-5,567 req/s. This is because Sharkbench limits each framework to 1 CPU core in Docker. Go’s goroutine model is designed for multi-core scaling — its per-core numbers are modest, but they multiply roughly linearly with available cores. On an 8-core machine, those numbers would be 3-6x higher.

Framework choice within a language matters enormously. Java Vert.x (23,116 req/s) versus Spring MVC (1,105-2,305 req/s) is a 10-20x difference within the same language. Node.js Fastify (9,340 req/s) versus Express (5,766 req/s) is a 1.6x gap. The framework you pick can matter as much as the language.

Bun has impressive raw speed but terrible stability — a 10.4% stability score means its P99 latency is nearly 10x its median latency. Fast on average, but unpredictable on the tail.

The JVM Warmup Question: Does It Pay Off?

This is the question Java developers ask most: after the JVM warms up and the JIT compiler kicks in, does Java actually become faster than Go, Rust, or C#?

Cold vs. Warmed Performance

The JVM doesn’t just run code — it learns from it. Through tiered JIT compilation, the C2 compiler identifies “hot” code paths and compiles them to highly optimized native machine code with aggressive inlining, escape analysis, and speculative optimizations based on runtime data.

The warmup effect is real and substantial. A payment service documented by Azul reduced time-to-peak-performance from 45 seconds to 12 seconds by pre-compiling 20 key methods. Teads, an ad-tech company, implemented a 2 minute 40 second warmup period before serving live traffic, which eliminated timeout spikes entirely.

HotSpot JVM vs. GraalVM Native Image

A Spring PetClinic benchmark by Vincenzo Racca measured the trade-off directly:

The JIT advantage is genuine but modest: 25% more throughput in exchange for 2.5x more memory and 33x slower startup. Whether that trade-off makes sense depends entirely on your deployment model.

At higher concurrency levels, the picture gets more interesting. The same benchmark at 200-300 concurrent users showed GraalVM Native Image actually edging out HotSpot JVM on throughput, likely because its lower memory footprint reduced GC pressure under load.

Does Warmed Java Beat Go or Rust?

No. The JVM warmup investment narrows the gap substantially but does not close it.

Values are requests/second and represent ranges across multiple benchmark sources. All measurements after warmup on multi-core hardware. Sources: TechEmpower R23, Sharkbench, index.dev: Java vs Go vs Rust Comparison

After warmup, Java reaches 60-80% of Go’s throughput and 40-60% of Rust’s for HTTP workloads. Java Vert.x and other reactive frameworks can approach or match Go and C# on median latency, but P99 latency remains significantly worse due to garbage collection pauses.

Where Java is competitive after warmup: mature thread pool management, excellent connection pooling, and the JIT’s ability to optimize hot paths based on actual runtime behavior — optimizations that ahead-of-time compilers can’t make.

Where Java still loses: raw throughput, P99 tail latency, and memory consumption per unit of throughput (10-30x more than Rust/Go).

Performance at Scale: 100, 1,000, and 10,000 Connections

Abstract benchmarks are useful, but the question that matters in production is: how do these frameworks perform at different levels of real concurrency?

100 Concurrent Connections (Low Load)

At low concurrency, most languages perform well. The differences are smallest here.

Sources: TechEmpower R23, Sharkbench, Travis Luong: FastAPI vs Fastify vs Spring Boot vs Gin

1,000 Concurrent Connections (Medium Load)

Performance starts to differentiate. Languages with efficient concurrency models pull ahead.

Sources: TechEmpower R23, 2024 Fastest REST API Servers

10,000 Concurrent Connections (High Load)

This is where architecture matters more than micro-optimization. Languages without efficient concurrent connection handling hit walls.

Sources: TechEmpower R23, Go: Managing 10K+ Concurrent Connections, How Fast Is ASP.NET Core? (dusted.codes)

The Scaling Gap Widens — Mostly

The ratio between the top and bottom tiers grows with concurrency:

But within the compiled tier (Rust, Go, C#, Java reactive), the gap actually narrows at high concurrency as the bottleneck shifts from CPU to I/O and connection management.

Elixir Phoenix deserves a special callout. Its raw throughput is moderate (4,000-8,000 req/s), but notice something remarkable: its P99 latency barely changes between 100 and 10,000 connections (15-40 ms vs 50-100 ms). Sharkbench measured Phoenix with the highest stability score of any framework at 84.9%. The BEAM VM’s preemptive scheduler ensures no single request can monopolize a CPU core, providing the most predictable latency profile of any runtime tested. If your requirement is “no request ever takes more than X milliseconds,” Phoenix is worth a serious look regardless of its moderate peak throughput.

Tail Latency: Where the Real Differences Live

Average response time is what you measure. Tail latency is what your users experience. P99 latency — the response time that 99% of requests beat — is where garbage collection, thread contention, and memory management show their true cost.

P99/P50 Ratio by Language

This ratio measures how consistent a language is. A ratio of 3x means the worst 1% of requests are 3 times slower than the median. A ratio of 20x means occasional requests are 20 times slower — visible as UI lag, timeout errors, and frustrated users.

Sources: Sharkbench stability scores, Why Tail Latency Matters (Medium), More Evidence for Problems in VM Warmup (Laurence Tratt)

Why This Matters More at Scale

The P99/P50 ratio worsens under higher load for garbage-collected languages. More allocations per second means more frequent GC cycles, and more concurrent requests means each GC pause affects more in-flight requests.

At 10,000 concurrent connections:

• Rust: P99/P50 stays at ~3-5x (barely changes from 100 connections)
• Go: P99/P50 stays at ~3-5x (goroutine scheduler handles load gracefully)
• Java (G1GC): P99/P50 grows to 20-50x (heap pressure triggers more aggressive GC)
• Node.js: P99/P50 grows to 10-20x (event loop congestion, backpressure)

Java’s answer is ZGC (production-ready since JDK 21), which brings GC pause times under 1 ms regardless of heap size. The trade-off is 5-10% lower throughput compared to G1GC. Most production Java deployments still use G1GC, but if P99 latency matters to your application, ZGC is the single most impactful configuration change you can make.

The GC Landscape

Sources: Baeldung: JVM Warm-Up, JVM Warmup Optimization (Java Code Geeks)

The Database Equalizer

Everything above measures compute-bound performance — how fast the language itself processes requests. But most real web applications don’t just process requests. They query databases. And that changes the picture dramatically.

How the Gap Compresses

TechEmpower runs six test types on the same hardware with the same PostgreSQL database. Watch how the performance spread changes as database involvement increases:

Source: TechEmpower Framework Benchmarks Round 23, GoFrame TechEmpower R23 Analysis

The performance gap between the fastest and slowest frameworks narrows from over 100x in plaintext to under 10x with database writes. This is the most important finding in this entire analysis for anyone building a typical web application.

Why? With 20 database queries per request, each taking 0.5-2 ms of round-trip time, the minimum request time is 10-40 ms regardless of language. A framework that processes its part in 0.1 ms (Rust) versus 2 ms (Python) only changes total response time from 40.1 ms to 42 ms — a 5% difference rather than the 20x difference you see in pure compute benchmarks.

The Fortunes Test: The Most Realistic Benchmark

TechEmpower’s Fortunes test is the closest to a real web application: fetch rows from PostgreSQL, add a row in memory, sort, HTML-escape, and render via a template engine. Here’s how the major frameworks performed on 56-core hardware in Round 23:

Source: TechEmpower Framework Benchmarks Round 23, TechEmpower R23 Announcement

Important caveats: Many top TechEmpower entries are micro-optimized beyond production reality — custom allocators, raw SQL, SIMD parsing. The ASP.NET “platform” entry at 300K+ excludes standard framework features; the realistic MVC version scores ~184K. Java Jooby at 404K is not Spring Boot; Spring Boot with Thymeleaf scores 3-5x lower. Use these numbers for relative rankings, not absolute expectations.

What This Means for Real Applications

If your application makes 5-20 database calls per request (which describes most CRUD applications, admin panels, e-commerce sites, and content management systems), the language performance difference drops to 2-5x between the compiled and interpreted tiers.

At that point, query optimization, indexing, connection pooling, and caching strategy matter more than language choice. A poorly-indexed Django application with N+1 queries will be slower than a well-optimized Laravel application with proper eager loading, regardless of Python being “faster” than PHP in compute benchmarks.

Memory Efficiency Under Load

One final dimension: how much throughput do you get per megabyte of memory consumed?

Source: Sharkbench Web Framework Benchmark, memory measurements during sustained load

Rust delivers 2,100 requests per second per megabyte of memory. Laravel delivers 4. That’s a 500x difference in memory efficiency — which translates directly to infrastructure costs when you’re scaling horizontally.

The Bottom Line

Here’s how to think about all of this data when making real technology decisions:

If latency consistency matters (fintech, gaming, real-time): Rust or Go. Their P99/P50 ratios stay stable under any load. If you need the JVM ecosystem, use ZGC.

If peak throughput matters (high-traffic APIs): Rust for absolute maximum. Go for 60-80% of Rust’s throughput with dramatically simpler code. Java Vert.x or C# ASP.NET Core if you need those ecosystems.

If your application is database-heavy (most web apps): The language matters 3-5x less than benchmarks suggest. Pick the language that makes your team most productive and invest in query optimization, indexing, and caching. Even Python and Ruby are adequate when the database dominates response time.

If you need massive concurrent connections (chat, IoT, WebSockets): Elixir Phoenix (proven at 2M+ concurrent connections) or Go (goroutines scale to 100K+ connections trivially). Java with Virtual Threads (JDK 21+) is now competitive here.

If infrastructure cost matters (microservices at scale): Go or Rust. The 10-30x memory efficiency advantage compounds across dozens of services. But consider whether a single Java monolith would actually use less total memory than 50 Go microservices.

If developer productivity matters most (startups, small teams): Pick the language and framework your team knows best. The 5-20x performance difference between frameworks matters far less than the 2-5x productivity difference between a team writing idiomatic code in their preferred language versus wrestling with an unfamiliar one.

The benchmark data is clear. The right choice isn’t.

Want to try any of these languages? Every language linked in this article has a dedicated page on CodeArchaeology with Hello World tutorials and Docker images to get you running in minutes. Browse our complete collection of 70+ languages.

Sources

Primary Benchmarks

• TechEmpower Framework Benchmarks Round 22/23
• TechEmpower Round 23 Announcement
• Sharkbench Web Framework Benchmark
• Travis Luong: FastAPI vs Fastify vs Spring Boot vs Gin
• 2024 Fastest REST API Servers

Java / JVM Performance

• Vincenzo Racca: Spring Boot vs GraalVM Performance
• Baeldung: JVM Warm-Up
• JVM Warmup Optimization (Java Code Geeks)
• JVM and Cache Warm-Up Strategy (Teads Engineering)
• Analyzing and Tuning Warmup (Azul)
• GraalVM Native Image vs Traditional JVM (Java Code Geeks)
• GraalVM Performance Boost (InfoQ)
• Java vs Go vs Rust Comparison (index.dev)

ASP.NET Core / .NET

• How Fast Is ASP.NET Core? (dusted.codes)
• .NET vs Node.js vs Spring Boot vs Django vs Go (BeyondTheSemicolon)

Tail Latency and GC

• Why Tail Latency Matters (Medium)
• More Evidence for Problems in VM Warmup (Laurence Tratt)
• Don’t Get Caught in the Cold (USENIX OSDI'16)

Framework-Specific

• YJIT 3.4: Even Faster (Rails at Scale)
• Ruby Application Servers 2025 (DeployHQ)
• Laravel Octane: Drivers, Benchmarks & Safe Adoption
• Phoenix: Road to 2 Million WebSocket Connections
• Go: Managing 10K+ Concurrent Connections

TechEmpower Analysis

• GoFrame TechEmpower R23 Evaluation
• TechEmpower R23 Analysis (Oreate AI)

Concurrency Models

• Why you can have millions of Goroutines but only thousands of Java Threads
• InfoWorld: Project Loom and Java’s New Concurrency Model
• Erlang Solutions: BEAM and JVM Compared