Laravel Octane is a first-party Laravel package that makes it super easy to serve your application via an artisan command while boosting its performance.
Why Use Laravel Octane?
Before Octane, we were used to the combo of Nginx + PHP-FPM, which works in this fashion:
- A request comes to Nginx.
- Nginx delegates the request to PHP-FPM.
- PHP-FPM either spawns a new worker or uses an existing one to handle the request.
- PHP-FPM worker boots your Laravel application.
- Laravel’s application handles the request.
- PHP-FPM returns the result to Nginx, which returns the output to the client.
As you can see, there’s an overhead of creating processes and booting Laravel’s application from scratch on every request.
NEW RESEARCH: LEARN HOW DECISION-MAKERS ARE PRIORITIZING DIGITAL INITIATIVES IN 2024.
How Does Laravel Octane Work?
Octane’s approach is to load the application once, keep it in memory, and serve every request without booting the application each time.
It uses two high-performance application servers: RoadRunner and Swoole.
Are you interested in using Octane to boost your applications’ performance? It will be helpful to take care of the following considerations.
Considerations
As Octane loads your application once and keeps it in memory, any changes you make in the code won’t be reflected when you refresh the browser. So when you’re developing, you should always start Octane in watch mode.
Octane handles resetting the state of any of Laravel’s first-party components, but it can not reset the global state created by your application. So, you should always consider these caveats when working with Octane.
1. HTTP Request Injection
You can type-hint the request instance on your controller methods and route closures, but you should avoid injecting it into the constructors of other objects.
It is safe to use the global helper `request()` in your application as it always returns the current request instance.
2. Service Container Injection
You should avoid injecting the application/container instance.
When you register a singleton into the service container, you should use a closure that resolves the application instance instead of directly passing the application instance.
For example, instead of using this:
$this->app->singleton(Service::class, function ($app) {
return new Service($app);
});
Use this:
$this->app->singleton(Service::class, function () {
return new Service(fn () => app());
});
It is safe to use the global helper `app()` and the `Illuminate\Container\Container::getInstance()` method in your application as they always return the current application container.
3. Memory Leaks
As Octane keeps your Laravel application running in memory, you need to take special care of global or statically maintained arrays. For example:
Service::$data[] = someOperation();
This will keep adding values to the static array $data[], resulting in a memory leak.
4. Testing
To test Octane-specific features, you can use Octane Testbench.
Benchmark
Let’s see how Laravel Octane (Swoole server) performs against Nginx + PHP-FPM (Laravel Valet).
Note: This benchmarking was performed on a MacBook Pro (M1 processor), and you might get different results when benchmarking on your server.
Simple String Response
Octane Serves ~53% More Requests Than Nginx + PHP-FPM
- Nginx + PHP-FPM: average of ~760 requests/second
- Octane (Swoole server): average of ~1170 requests/second
Running 5 Queries Before Returning a Response
Octane Serves ~87% More Requests Than Nginx + PHP-FPM
- Nginx + PHP-FPM: average of ~540 requests/second
- Octane (Swoole server): average of ~1000 requests/second
Conclusion
Octane takes Laravel applications’ performance to a new level. However, it brings with it some considerations because of the way it works.
Interested in trying it out? I’ve prepared a Laravel application with Sail preconfigured to run an Octane server – https://github.com/mustafarefaey/octane-demo. For more information on Laravel Octane, check out its official documentation.
