Your Laravel app takes 200ms to respond to a simple request? At 10 requests per second the server starts struggling? The problem isn't the framework — it's PHP's lifecycle. Every request starts from scratch: bootstrap, autoload, service container, middleware. Laravel Octane breaks this pattern by keeping the application in memory. We at Meteora Web have been using it on high-traffic projects since day one. Let's see how Swoole and FrankenPHP work, two engines that bring PHP into persistent server territory.
What problem does Laravel Octane solve with Swoole and FrankenPHP?
Traditional PHP is stateless by design. Each HTTP request starts from zero: loads the bootstrap, instantiates the container, registers providers, runs middleware, and only then reaches the controller. With Octane, the app is loaded once into a worker process that stays in memory. Subsequent requests reuse everything. The savings are massive: from 100-200ms per request down to 5-15ms. The difference? A virtual server instead of a new PHP process per request.
Swoole is a C extension for PHP that implements an event loop and an embedded HTTP server. FrankenPHP is an app server written in Go that runs PHP through an embedded worker, built by the Symfony team. Both work with Laravel Octane without changing your application code. Choose based on your existing infrastructure.
Sponsored Protocol
How does Octane work with Swoole vs FrankenPHP?
With Swoole: a true async server in PHP
Swoole turns PHP into an async runtime: worker processes stay alive, handle requests in an event loop, and can share state (with care). Octane integrates Swoole as a driver. To install:
# Install Swoole extension
pecl install swoole
# Add to php.ini
extension=swoole.so
# Install Octane
composer require laravel/octane
php artisan octane:install --server=swoole
Start with php artisan octane:start --server=swoole --workers=4. Octane generates a config file config/octane.php where you can set the number of workers, port, and Swoole options (e.g., max_requests for memory leak prevention).
Note: Swoole requires the extension to be installed at the server level. Not all shared hosting supports it. On VPS or containers it's perfect.
With FrankenPHP: a Go server that speaks PHP
FrankenPHP is a bundle: it includes an HTTP server in Go (Caddy underneath) that runs PHP through a native worker process. No extra PHP extensions are needed — just the FrankenPHP binary. Octane supports it as a stable experimental driver since v1.3.
Sponsored Protocol
# Install FrankenPHP (example on Linux)
curl -sS https://frankenphp.dev/install.sh | sh
# Or use Docker
docker run -v $PWD:/app dunglas/frankenphp
# Configure Octane
php artisan octane:install --server=frankenphp
php artisan octane:start --server=frankenphp --workers=4
FrankenPHP has the advantage of not tying you to custom PHP extensions: it's a single binary. It also handles TLS natively (thanks to Caddy) and hot-reload of workers. For containerized projects, it's the cleanest choice.
What performance gains can you expect from Laravel Octane?
We measured on one of our own projects with Laravel 11, 20 API endpoints, local MySQL. With php-fpm (8 workers): ~180ms per request, 1200 req/s peak. With Octane+Swoole (4 workers): ~12ms per request, 5800 req/s stable. Throughput quadrupled and latency dropped dramatically. On an e-commerce shop with traffic spikes, Octane let us handle Black Friday with 8 workers instead of 20 containers.
Sponsored Protocol
No magic: workers consume RAM continuously. Each worker can take 50-100MB. On a 1GB server, 4 workers is the max. FrankenPHP is slightly lighter on RAM because the Go worker is leaner than the Swoole process.
How to measure the real impact on your project?
Before migrating, run a baseline benchmark. Use ab (Apache Bench) or wrk:
# Benchmark with php-fpm
wrk -t4 -c50 -d10s http://your-domain/api/test
# Benchmark with Octane
php artisan octane:start --server=swoole --workers=4
wrk -t4 -c50 -d10s http://localhost:8000/api/test
Compare average latency, 99th percentile, and throughput. Octane should show 10-20x lower latency. If the difference is small, check if the bottleneck is the database or an external API — Octane doesn't speed up logic, it removes bootstrap overhead.
What to do now to adopt Laravel Octane?
- Verify compatibility: Check that all facades and helpers used in your code are thread-safe. Octane runs requests in coroutines (Swoole) or concurrent workers (FrankenPHP). Global variables, statics, and unmanaged singletons can cause race conditions. Laravel is designed to be stateless, but some libraries or legacy code may break.
- Choose your server: If you have full control over infrastructure and want max performance, go with Swoole. If you use Docker or want simple deployment, pick FrankenPHP.
- Configure workers: For each CPU core, set 1-2 workers. Monitor memory with
free -m. Increasemax_requests(e.g., 500) to prevent memory leaks: Octane will recycle the worker after that many requests. - Test in staging: Don't deploy to production without running your full test suite. Octane exposes dormant concurrency bugs.
- Consider RoadRunner: It's also supported by Octane. Similar to FrankenPHP but with a different ecosystem. If you already use RoadRunner, stick with it.
We at Meteora Web chose Laravel Octane for projects that require low latency and horizontal scaling. For a deeper look at the full Laravel architecture, check our Laravel Framework Complete page. For technical details, the official Octane docs are the best reference.
