Laravel Octane: making PHP scream on high-traffic apps

Standard PHP is a bit like a restaurant that fires its entire staff and rebuilds the kitchen from scratch for every single customer order. You walk in, they hire a chef, buy a stove, cook your meal, and then demolish the building as soon as you leave. It’s consistent and safe, but it’s a massive waste of energy when you’re trying to serve thousands of people at once.

This is the PHP-FPM lifecycle. Every request boots the entire Laravel framework, loads your service providers, parses your config, and instantiates your objects. For low-traffic sites, it’s fine. But when you hit real scale, those milliseconds of “boot time” become a wall you can’t climb without throwing excessive amounts of expensive hardware at the problem. Horizontal scaling buys you room, but it doesn’t fix the underlying latency.

The solution is to stop rebuilding the kitchen. Laravel Octane changes the game by booting your application once, keeping it in memory, and then feeding requests to it through a high-performance worker pool. It transforms PHP from a “short-lived script” language into a “long-lived process” powerhouse.

Why your app feels heavy

The overhead of traditional PHP isn’t just about speed; it’s about efficiency. In a standard request, your CPU spends a significant chunk of time just getting the application ready to do work. Once it finally starts execution, it does the database query, renders the view, and then dies.

If you’re running a complex Laravel monolith with dozens of packages and custom service providers, your boot time might be 30ms to 50ms before a single line of your actual business logic even runs. Under high traffic, this leads to CPU thrashing. You’re paying for the “setup” over and over again.

Laravel Octane removes this boot cycle. By using high-performance application servers like Swoole or RoadRunner, your app stays resident in memory. The first request boots the framework, and subsequent requests hit a “warm” application. We’re talking about moving from 50ms responses to sub-10ms responses just by changing how the process is managed.

Swoole vs RoadRunner: choosing your engine

When you drop Octane into your project, you have to choose between two primary engines: Swoole and RoadRunner. I’ve used both in production, and while they both solve the “persistent state” problem, they do it differently.

Swoole

Swoole is a C++ extension for PHP. It’s essentially a high-performance networking engine that allows PHP to handle asynchronous tasks, coroutines, and long-lived connections.

• Pros — it is incredibly fast. Because it lives as an extension, it has deep access to PHP’s internals. It also gives you access to the “Octane cache,” an in-memory store that’s significantly faster than Redis for local data.
• Cons — it can be a bit of a nightmare to install and debug. Because it’s a binary extension, you have to compile it or find the right package for your OS. Xdebug doesn’t always play nice with it, and it can be picky about your environment.

RoadRunner

RoadRunner is written in Go. It acts as a load balancer and process manager that communicates with your PHP workers via a high-speed binary protocol (Goridge).

• Pros — no extensions required. It’s a single binary you drop into your project. It’s much easier to set up in a Docker container and generally feels more “cloud-native.”
• Cons — it’s slightly slower than Swoole because of the communication overhead between the Go binary and the PHP processes, though for 99% of apps, this difference is negligible.

For most developers starting out with Octane, I recommend RoadRunner for the ease of use. If you are chasing every last millisecond and need features like async task workers, go with Swoole.

Tuning your worker pool

The secret sauce of Octane is the “worker pool.” Instead of one process per request, you have a fixed number of workers waiting to handle incoming traffic. If you misconfigure this, you’ll either leave performance on the table or crash your server.

A general rule of thumb for sizing your worker pool depends on whether your app is CPU-bound or I/O-bound.

1. CPU-bound apps — if you’re doing heavy data processing or image manipulation, set your worker count to the number of CPU cores you have. Adding more workers will just cause context switching and slow things down.
2. I/O-bound apps — most web apps spend 90% of their time waiting for a database, Redis, or an external API. In this case, you can scale your workers to 2x or even 4x your core count. This allows one worker to wait for the DB while another handles a new request.

# Starting Octane with 16 workers for an I/O-heavy app
php artisan octane:start --server=swoole --workers=16

Don’t forget about task workers if you’re using Swoole. These are separate from your HTTP workers and are perfect for offloading slow tasks like sending emails or processing webhooks without blocking the main request cycle.

The danger of persistent state

The biggest hurdle when moving to Octane is the shift in mindset. In traditional PHP, “leaky” code doesn’t matter much because the process dies after 100ms. In Octane, a memory leak is a ticking time bomb.

If you have a static array in a service provider that you append to on every request, that array will grow until your server runs out of RAM. You have to be extremely careful with:

• Static properties — avoid using them for request-specific data.
• Singletons — if you register a singleton in your app container, it stays alive. If that singleton caches data, you need to make sure that data is cleared or managed properly between requests.
• Global state — avoid global variables at all costs (which you should be doing anyway).

Laravel helps you by “resetting” some core services between requests, but it can’t catch everything. If you’re migrating an old codebase from monolith to microservices, you’ll want to audit your service providers for any long-lived state.

Protecting yourself with max-requests

The best insurance policy against memory leaks is the --max-requests flag. This tells Octane to kill and restart a worker after it has handled a certain number of requests.

# Restart workers every 1000 requests to prevent memory bloat
php artisan octane:start --max-requests=1000

This keeps your memory usage predictable while still giving you the performance benefits of a warm application.

Real-world optimization tips

Once you have Octane running, there are a few technical levers you can pull to squeeze out even more performance.

1. Connection pooling — ensure your database connections are persistent. In Octane, your workers stay alive, so they can hold onto their DB connections instead of reconnecting every time. Check your database.php config and ensure you aren’t hitting the max connection limit on your DB server.
2. Octane cache — if you’re using Swoole, use Octane::cache(). It’s an in-memory table that’s blistering fast. Use it for frequently accessed configuration or small datasets that don’t change often.
3. Bytecode caching — make sure OPcache is enabled and tuned. Set opcache.validate_timestamps=0 in production since your code won’t be changing while the server is running.
4. Graceful reloads — when you deploy new code, use php artisan octane:reload. This will gracefully restart the workers without dropping current connections. It’s essential for zero-downtime deployments.

Takeaways for the high-traffic dev

Transitioning to Octane isn’t just about installing a package; it’s about maturing your infrastructure.

• Identify the bottleneck — only use Octane if your boot time is the problem. If your database queries take 2 seconds, Octane won’t help you.
• Test for leaks — watch how your app behaves under sustained load and profile its memory growth over time.
• Monitor workers — keep an eye on your CPU and RAM usage to find the “sweet spot” for your worker count.
• Leverage concurrency — use Octane::concurrently() to execute multiple tasks at once and return their results, cutting down total response time for complex pages.

Octane takes PHP to a level where it can compete with Node.js and Go for high-concurrency applications while keeping the developer experience of Laravel intact. If you’re building a SaaS that expects a lot of noise, this is your jet engine.

Are you running Octane in production yet, or is the fear of memory leaks keeping you on PHP-FPM? Drop a note via contact — let’s talk worker counts. 🤘