Laravel Octane is the latest offering from the Laravel Team. It boosts our Laravel Application with supersonic speed by utilizing Swoole and RoadRunner. It bootstraps the Laravel framework dependency container, saves it in RAM, and thus cuts the bootstrapping process from each request and provides blazing-fast responses.
What is Octane?
Laravel Octane is a wrapper behind the high-performance servers, Swoole and RoadRunner. Swoole is a PHP extension, which, upon installing, provides us with a myriad of cool and nitty-gritty features such as coroutines, fibers, web-sockets, caching, and so on. On the other hand, RoadRunner is a high-performance application server, load-balancer, and process manager written in GoLang. Octane utilizes one or the other, depending on the developer itself. Nevertheless, it’s worth saying that by using the PHP Swoole extension, Octane gets much more handy features than with RoadRunner.
The idea is that you can get up and running in seconds with Octane if you choose RoadRunner as it’s just a GoLang binary file, and you need to download it, and you’re good to go. As for installing the PHP Swoole extension can become a complex and little cumbersome process, but the end result is way better as it gives you much more features than RoadRunner.
How does Octane work?
The developers love Laravel; even so, there is to raise an issue regarding the performance. We’re not saying that Laravel is slow, but at the very least, it’s not the best beast in the field. Laravel Octane tries to cut that issue in half.
First, let’s understand how Laravel Application is traditionally served under a web server. After a web-server(Apache or Nginx) gets a request, it then delegates the request to PHP-FPM, starting a new worker or reusing the available one.
A worker spawns the new process upon executing a PHP script. After which PHP will include all the files associated with the Laravel Project, and it’s going to read them from the hard disk, and reading from hard disk is always time and resource consuming. Then PHP will bootstrap the Laravel Framework and its dependency container, which most of the time takes much more time and resources than executing business-specific logic.
And finally, our business logic is executed. The idea is that creating new processes, including all those many files from the disk, bootstrapping framework is just time and resource-consuming, and it happens on each and every request. So then, what can Laravel Octane do about it?
Laravel Octane simply caches bootstrapped laravel framework in the RAM on the first request. Every request after it just uses the already bootstrapped framework from the RAM instead of reading the files from the hard disk and re-bootstrapping the framework. And that’s the core idea that boosts the framework performance so much.
Caveats to Consider
Even though Octane supercharges your Laravel application, you should consider some issues before jumping in this boat.
The idea that Octane saves a bootstrapped framework in the RAM means that Laravel Application becomes stateful. Quite simply, any runtime changes to the class instances, class static properties, and variables are preserved. And every variable and instance that you created during the request is preserved and available to each and every subsequent request.
So it is the perfect environment for memory leaks. Worst of all, we, PHP programmers, aren’t used to thinking about garbage collection and memory leaks and stuff like that because traditional applications would isolate one process for each request. After sending the response, the process would immediately die. So each request would be sandboxed in their process, and memory leaks become next to impossible as all the memory gets freed at the time of process termination.
But the Laravel team tries to reduce such traps and possibilities where memory leaks can happen. So, they’re reusing the Dependency Container assembled on the first request. Dependency Container is the core of the laravel foundation, and it’s a cornerstone of the framework. The Dependency Container takes care of auto wiring, resolving/registering/providing services, and so on. As it is the core component of the framework, Laravel Team decided that it would be better if they made it cross-request immutable. And so, this is what happens.
When the Octane server is initiated, on the first request, the framework is bootstrapped and saved in shared memory, and also the Dependency Container is saved separately. Let’s call it the Original Dependency Container. Then, on each and every subsequent request, this Original Dependency Container is cloned and provided for this request. After the request is terminated, this clone gets destroyed. And on the upcoming requests, the same scenario is played.
The idea is to always have the Original Dependency Container on every request, and if the Container is modified, it should not affect the other upcoming requests. Therefore, we can say that the Octane-powered Laravel application is partially stateful. However, as Mohamed Said, a member of the Laravel Team, noted, PHP libraries and developers aren’t ready for Laravel to become completely stateful. So, when working with Dependency Container and Service Providers, keep in mind that Octane preserves Dependency Container, and everything should be okay.
Also, keep in mind that the Octane-powered Laravel application is different from the traditional Laravel application. Octane has its server, and web servers like Nginx and Apache should only redirect incoming traffic to the Octane Server and pass additional proxy headers if necessary. Another caveat is that you need to start the Octane server in watch mode during the development process for the server to auto-restart on code changes. That’ll be very familiar if you have a little bit of Node background.
“In a post-opcache, post-octane world – I see no reason to choose Lumen for a new project,” – Says Taylor Otwell, Creator of Laravel.
Lumen is a micro-framework based on Laravel, frankly speaking, it’s a Laravel framework without some of the components to make it fast. So Laravel with Octane as its server is way more performant than Lumen. Let’s see some real numbers, shall we?
I decided to stress test the Laravel application in 3 modes:
- Laravel with Octane
- Laravel with Apache WebServer(traditional approach)
- Laravel with its Built-In Server
Well, the results were as you might have imagined. For testing, I used well known, popular tool wrk, with the following configuration:
wrk -t1 -c50 URL
And the testing route was responding with just Hello World HTML, nothing fancy, but even with that, the result is quite interesting.
|Laravel Mode||Handled Request in 10 Seconds||RPS – Request per Second|
|Laravel with Octane||2667||266 rps|
|Laravel with Apache||1210||121 rps|
|Laravel with Built-In Server||705||70 rps|
So, as it appears, Laravel with Octane as its server is at least twice as fast as traditional Apache-Served Laravel.
Benefits of Swoole
As I mentioned earlier, if you are to use Octane, it’s way better to go about it with the Swoole PHP extension, as it provides some additional cool features. Of course, the Swoole extension itself is a whole other story, and it should have an article of its own, but let’s, for now, dive into what we can get from Swoole with the Octane.
Concurrent Tasks – one of the cool features of Swoole is concurrency. You can do several tasks at once. It is not full-fledged thread support, but even this small addition of concurrency in PHP may come unbelievably handy. For example, as shown below in the picture, you can use available threads and make several asynchronous queries on the database. And it’s not limited to the database; you can do any work with Concurrent Tasks.
Ticks & Intervals – Traditionally, as we’ve already said many times, Laravel is not stateful, meaning – every request has its own PHP script execution, and there is no built-in server in production applications. For that reason, tasks that are to be executed in the scheduled timeline are triggered with the help of a Linux built-in cron. But with Octane, Laravel gets statefulness and its own server, and it does not need cron to trigger some actions in a scheduled manner. All this logic can be done within the Octane server. And to utilize that functionality, we need to register our scheduled tasks in the boot method of the Service Provider with the help of Octane Ticks, and Octane will take care of triggering those tasks.
The Octane Cache – And so, there come more perks with statefulness. With the ability of Swoole Tables and statefulness, we can now enjoy the new, lightning-fast cache repository – The Octane Cache. As documentation tells us, it’s capable of 2 million operations per second – reads and writes, which is just mind-blowing! The only drawback to this caching system is that it will flush whenever we restart or stop the Octane server, as it is persisted in the shared memory – RAM.
Should you start using Octane right now?
Laravel Octane is a mind-blowing offering from the Laravel team, which provides a performance boost in so many ways. But with great power, there come great responsibilities. As I said earlier, we PHP developers aren’t used to thinking about statefulness and its headaches – garbage collection, memory leaks, etc.
So if you know that your application just does not need that much supersonic performance, it may be a better option to stay with the traditional approach. And if it were to require that performance boost, it’s not that hard to upgrade your traditional Laravel app with an Octane-powered beast. As for those apps where performance is of the essence, I would suggest not to hesitate and jump right in! You don’t need to start learning Node because of the business requirements; you can stay with your favorite tool and charge it with Octane.
Written by Giorgi Giunashvili