Running 1 Billion Requests Through 5 Popular Web Frameworks

💡 Conducting a bold experiment: running 1 billion requests through 5 popular web frameworks to evaluate their responsiveness under extreme load.

⚠️ Important Disclaimer Before Reading

This is not just a simple benchmark. The author set up a realistic production environment, fully integrated observability, and used wrk2 and k6 for stress testing. The main goal is to see which framework actually "survives" when facing massive load.

Metrics like RPS (Requests Per Second) and memory consumption (RSS) are only part of the evaluation process. Choosing a framework for a project requires holistic consideration: ecosystem, community, development speed, maintainability, and team familiarity. The benchmark results below are for reference only and should not be the sole criteria for technological decisions.

1️⃣ List of 5 Selected Frameworks

The lineup includes 5 popular frameworks that have been battle-tested and favored by developers in 2025:

• Go (Gin): Lightweight, compiled, known for its speed.
• Rust (Actix-Web): Memory-safe, great low-level control, often leading benchmark charts.
• Node.js (Fastify): Asynchronous, JavaScript-native, optimized for speed.
• Python (FastAPI): Developer-friendly, supports async.
• Java (Spring Boot): Popular in enterprise, powerful but consumes a lot of RAM.

📌 Each framework was tested with a basic, realistic REST endpoint: parse JSON → query database (PostgreSQL) → return JSON response.

2️⃣ Test Scenario & Environment

🖥️ Infrastructure

• VM with 4 cores, 16GB RAM on GCP
• All services deployed via Docker containers
• PostgreSQL using connection pooling

📊 Tools & Methodology

• Used wrk2 for load testing with a constant rate
• Load gradually increased from 100 to 100,000 RPS, totaling 1 billion requests

📈 Monitoring Metrics

• Requests per second (RPS)
• Latency at 95th and 99th percentiles
• Memory usage (RSS)
• CPU utilization
• Error rate under load
• Connection handling & resilience

3️⃣ Detailed Test Results

🔹 Go (Gin)

• Performance: Maintained >100,000 RPS, latency consistently < 10ms. Stable garbage collector, memory < 200MB.
• ✅ Pros: Extremely small memory footprint, fast JSON serialization, latency barely increases under high load.
• ⚠️ Cons: The ecosystem is not as diverse as Java/Python in some specialized areas (although its backend system is excellent).

🔹 Rust (Actix-Web)

• Performance: Faster than Go, lowest tail latency (outstanding P99). Requires a lot of boilerplate and tuning.
• ✅ Pros: Best latency at extremely high concurrency, lowest error rate.
• ⚠️ Cons: High complexity, steep learning curve (requires adapting to its coding paradigm and memory management).

🔹 Node.js (Fastify)

• Performance: Stable throughput ~60,000 RPS, good async processing. Memory 500–700MB, GC caused a few minor spikes but no crashes.
• ✅ Pros: Great async scalability, efficient JSON processing, large community and rich documentation.
• ⚠️ Cons: Latency spikes due to GC, higher memory consumption than compiled languages.

🔹 Python (FastAPI)

• Performance: Fine under low load, but bottlenecks when >10,000 concurrent requests. CPU maxed out, memory >1.2GB, response time skyrocketed.
• ✅ Pros: Friendly syntax, readable, easy to maintain, great for AI/ML integration.
• ⚠️ Cons: Performance degrades sharply under high concurrent load, high memory consumption due to the GIL and runtime overhead.

🔹 Java (Spring Boot)

• Performance: Stable but heavy. Slow cold start, >1GB RAM idle. Requires careful JVM/GC tuning. Can maintain ~40,000 RPS without errors.
• ✅ Pros: Long-standing, stable ecosystem, full enterprise features, excellent security & configuration management.
• ⚠️ Cons: Slow cold starts, resource-heavy, requires complex configuration for optimal performance.

4️⃣ Benchmark Summary Table

5️⃣ Conclusion & Notes

The article has been adjusted, removing some inaccurate information from the original to ensure technical objectivity and accuracy. The results above only reflect performance in a specific test scenario (single endpoint, JSON + PostgreSQL, constant rate load).

In reality, choosing a technology should be based on:

• Business requirements & project SLAs
• Team capabilities & experience
• Operation, maintenance & scaling costs
• Ecosystem & integration capabilities

A benchmark is a reference tool, not an absolute measure. Choose the technology that best fits your actual context.

📖 Original Reference:
I tried running a billion requests through 5 web frameworks, here's what survived (Medium)

💡 The article has been restructured, technical terms standardized, and formatted to fit technical blog/internal report standards.