Why Web Systems Collapse Under Real Load — and Why We Keep Believing the Benchmarks
“In the lab, PHP served 12 million operations per second. In production, it barely reaches 500 requests per second.”
This is not an exaggeration. It is the difference between the controlled environment and the real world.
Every week, we are fed magical numbers: “Redis does 100,000 ops/sec”, “Node.js handles thousands of concurrent connections”, “Laravel is fast and secure.”
But when real users arrive, when network latency kicks in, when threads start fighting for resources — those numbers evaporate like a bad dream.
The question is not “which language is fastest?”
The real question is: “Why do we spend 90% of CPU time on preparation, and only 10% on execution?”
I. The Bootstrapping Tax
Rebuilding the house for every visitor
Imagine owning a house. Every time a visitor arrives, you demolish the entire building, reconstruct it from scratch, and then open the door. After they leave, you demolish it again.
This is exactly what modern frameworks do on every single request.
- Laravel / Rails — loads 50+ Service Providers, builds a DI container, registers routes, initialises connections.
- Spring Boot — loads context, scans annotations, builds beans, initialises data sources.
- Django — loads apps, initialises middleware, builds the ORM, prepares templates.
The result: 70–90% of CPU time is spent on preparation, not on execution.
“Why do we design a system that consumes 90% of its resources on preparation and only 10% on execution?”
II. Threads — The Silent Killer
The thread that doesn’t work, but waits
If Bootstrapping is the wound, then Threads are what make that wound bleed to death.
Under load, threads are held hostage: they wait for I/O, they wait for locks, they wait for connection pools — they spend most of their life doing nothing.
- Nginx/Apache — assigns a thread/process per request. Under high load, the thread pool exhausts, requests pile up.
- PHP-FPM — fixed number of children. When requests arrive faster than children can process, they queue and then get refused.
- Laravel Bootstrapping — happens inside the thread, preventing it from handling other requests.
- Redis (Network I/O) — the thread blocks, waiting for Redis. Blocking I/O is the executioner.
The result: a slow, painful cascade of accumulation, contention, and collapse.
The deadly embrace: Threads + Connection Pools
Imagine: 10 Redis connections, 50 PHP-FPM children, and 100 concurrent requests.
- 40 children grab the 10 connections and wait for Redis.
- 10 children wait for a free connection (blocking).
- New requests pile up in the queue.
- The system enters a deadlock spiral.
“Threads are not bad. But we use them badly. We make them wait instead of work.”
III. Protocol Overhead
When protocols become the enemy of performance
HTTP was designed in the 1990s to serve HTML pages. Today we use it for JSON, WebSockets, streaming, and real-time data. Each layer we add, we pay for:
- TCP Handshake — 1–3 ms (or more on slow networks)
- TLS Handshake — 2–5 ms (HTTPS)
- HTTP Headers — 0.5–2 ms
- Request Parsing — 0.5–1 ms
- Response Serialization — 1–3 ms
The Stateless trap
In the web, every request is a fresh start. No shared context between requests — even from the same user. This makes scaling easy, but performance abysmal.
“We re-introduce the user to the system 100 times per session, as if we’ve never met them before.”
IV. Why Current Solutions Fail
1. Serverless — shifting cost, not solving it
Serverless does not reduce bootstrapping. It hides it behind a “pay-per-use” curtain. And on cold starts, the nightmare returns — often worse, with added latency of several seconds.
2. Microservices — network hell
Instead of one codebase, you now have 20 services communicating over the network. Each request becomes a chain of network calls.
- Auth service → network call
- Users service → network call
- Orders service → network call
- Notifications service → network call
Result: total latency = sum of all network RTTs. Threads wait across services, multiplying the deadlock risk.
3. Persistent systems (RoadRunner, Swoole) — memory nightmares
They solve bootstrapping, but introduce memory management hell:
- Memory leaks accumulate fatally.
- Code reload needs careful orchestration.
- State management across threads requires locks, increasing contention.
“Microservices are not a solution to performance. They are a transfer of the problem from one codebase to an entire network.”
V. The Performance Decay Graph
Before we look at the numbers, picture this:
OPERATIONS PER SECOND
──────────────────────►
10M │ ████ (Raw Sockets)
│ ████
1M │ ███ (+PHP)
│ ███
100K │ ██ (+HTTP)
│ ██
10K │ █ (+PHP-FPM)
│ █
1K │ ░ (+Laravel Boot)
│ ░
500 │ ░ (+Redis/ORM)
└─────────────────────►
C1 C2 C3 C4 C5
Each step to the right is a new layer of “convenience”.
Each step upward is lost performance.
This is the graveyard of modern web engineering.
Latency per Layer (ms)
| Layer | Latency (ms) |
|---|---|
| 0. Raw Sockets (C) | 0.0001 |
| 1. + PHP (Sockets) | 0.1 |
| 2. + HTTP (Nginx) | 1.0 |
| 3. + PHP-FPM | 5.0 |
| 4. + Laravel Boot | 20.0 |
| 5. + Redis (Network) | 25.0 |
| 6. + Eloquent (ORM) | 50.0 |
Thread Multiplication Factor (real vs theoretical)
| Layer | Threads (real) |
|---|---|
| 0. Raw Sockets (C) | 1 |
| 1. + PHP (Sockets) | 3 |
| 2. + HTTP (Nginx) | 12 |
| 3. + PHP-FPM | 48 |
| 4. + Laravel Boot | 192 |
| 5. + Redis (Network) | 384 |
| 6. + Eloquent (ORM) | 768 |
Throughput Collapse (requests/sec)
| Layer | Throughput (req/s) |
|---|---|
| 0. Raw Sockets (C) | 10,000,000 |
| 1. + PHP (Sockets) | 200,000 |
| 2. + HTTP (Nginx) | 50,000 |
| 3. + PHP-FPM | 10,000 |
| 4. + Laravel Boot | 2,000 |
| 5. + Redis (Network) | 1,500 |
| 6. + Eloquent (ORM) | 500 |
Interpretation: From 10 million ops/sec at the bare metal down to ~500 requests/sec with Laravel + ORM + Redis.
Each layer adds latency, consumes threads, and collapses throughput.
VI. Towards a New Engineering — Principles Only
All current solutions try to improve the existing stack. But the stack itself is the problem.
Core principles for a different path
- Minimise Bootstrapping — load code and resources once. Reuse context across requests.
- Eliminate Blocking I/O — prefer non-blocking I/O. Reduce network dependency for data access.
- Manage threads intelligently — reduce contention. Use atomic operations over locks.
- Data Locality — bring compute to data, not data to compute. Zero-copy where possible.
- Stateless for scale — but be aware of the trade-offs.
“The solution is not to make the language faster. It is to change how we access data. Not to improve tools, but to redesign the system.”
Conclusion: The Coming Battle
“If bootstrapping is the number one enemy of performance, why do we still rebuild the house for every visitor?”
We stand at a crossroads:
- Path one: Keep buying more servers to compensate for bloated code.
- Path two: Redesign the way we access data.
The coming battle is not between programming languages. It is between deliberate engineering and blind assembly.
“We buy servers with 32 cores and 64 GB RAM, yet we use them as if they were machines from the 1990s. Not because the CPU is slow, but because we make threads wait. We wait for bootstrapping. We wait for the network. We wait for connections. The thread does not work. It waits. And in the world of the web, waiting is death.”
Principles alone are not enough to build a system. But they are enough to change how you think.
About the author
Ez Eldeen A. Mushtaha deconstructs dogmatic models, cosmological dogmas, and messy code. He believes that real engineering begins when you stop believing marketed numbers and start measuring reality.
Originally published on Medium — all rights reserved.
Top comments (0)