Is PHP DEAD? I’ve seen countless posts and hot takes claiming PHP is a relic of the past. But every time I see one of those threads, I genuinely wonder if the author has touched PHP in the last few years—because modern PHP comes packed with incredible tooling and performance that completely disrupts that outdated narrative.
Have you actually tried the Octane + Swoole + Caddy stack?
When you move away from the traditional request-lifecycle paradigm—where PHP boots up the framework, executes a single request, and tears everything down—and switch to long-running, application-in-memory workers, the entire game changes.
Running Laravel Octane with Swoole (or RoadRunner) behind a modern Caddy server gives you:
- Persistent database connection pools
- Async / coroutine execution
- Response times in single-digit milliseconds under real load
Have you done real benchmarks, or are you just relying on old blog posts?
A lot of the "PHP is slow" rhetoric comes from synthetic benchmarks comparing a bare-bones Go or Rust HTTP handler against an unoptimized, legacy FPM setup running behind a default web server installation.
That isn't testing language performance; that's comparing two entirely different architecture paradigms.
When you benchmark persistent, async PHP application workers against other popular web stacks under actual concurrency, PHP holds its ground remarkably well.
Ecosystem & Server Stacks Comparison
| Tool / Stack | Primary Role | Execution Paradigm | Key Strengths & Production Profile |
|---|---|---|---|
| Laravel Octane | Application Orchestrator | Persistent / In-Memory | Keeps framework booted in memory; manages Swoole, RoadRunner, or FrankenPHP workers. |
| Swoole | Async Engine / Extension | Persistent C-Extension | Coroutine-based async I/O, WebSockets, ultra-low latency, and massive request throughput. |
| FrankenPHP | Modern App Server | Go/Caddy-based Persistent Server | Native worker mode, automatic HTTPS, HTTP/3 support, single-binary deploys, native Octane support. |
| Caddy | Reverse Proxy / Web Server | Event-driven (Go) | Zero-config automatic TLS, lightweight, modern syntax; perfect proxy for persistent PHP apps. |
| Nginx | Reverse Proxy / Web Server | Event-driven Master/Worker | High stability, industry standard for proxying to PHP-FPM or persistent app servers. |
| LiteSpeed (OLS) | Web Server | Event-driven (LSAPI) | Fast static asset handling, .htaccess compatibility, optimized process management. |
| Apache | Traditional Web Server | Process/Thread MPM | Modularity, legacy compatibility; heavier under high concurrency compared to event loops. |
Where modern PHP (8.4 & 8.5) stands on performance
The runtime itself has transformed:
- PHP 8.4 introduced a rebuilt JIT implementation (IR framework), property hooks, asymmetric visibility, lower memory consumption, and significant opcode execution optimizations.
-
PHP 8.5 brings developer ergonomics like the native pipe operator (
|>), array functions (array_first,array_last), and further internal runtime polish.
Between JIT improvements, strict static typing capabilities, OPcache, and async event loops via Swoole or Fibers, CPU and I/O bottlenecks aren't what they used to be.
Are you still using Apache, Nginx, or LiteSpeed just out of habit?
Nginx and LiteSpeed are reliable, but sticking with traditional web server configurations out of pure routine often keeps applications tied to older deployment patterns.
Putting a lean Caddy server (with native HTTP/3, automatic TLS management, and minimal reverse-proxy overhead) directly in front of an in-memory Swoole/Octane app worker gives you a clean, low-latency setup that is trivial to maintain.
Do you only evaluate the programming language, or do you actually tune your server and OS?
Language benchmarks mean very little if the underlying operating system is neglected.
- Are you tweaking Linux kernel parameters (such as
somaxconn, ephemeral port ranges, and open file limits)? - Are you selecting the right OS distribution and tuning worker allocations to match physical CPU core topology?
- Are you configuring OPcache memory limits correctly?
A well-tuned Linux box running modern PHP with memory persistence will easily outperform an unoptimized Node or Python service.
PHP isn't dead—it evolved while many people weren't paying attention. But getting these results requires stepping away from 2015 deployment habits and treating server infrastructure with the same engineering discipline as application code.
Let's discuss 💬
How are you running PHP in production today? Have you run your own benchmarks with Octane, Swoole, or FrankenPHP, or what server stack are you relying on? Drop your setup and thoughts below!
Top comments (0)