Laravel Vapor is a serverless deployment platform for Laravel applications. It allows developers to deploy their Laravel applications to the cloud without having to worry about server management, scaling, or infrastructure.
Laravel Octane is a high-performance application server that’s built specifically for Laravel. It can be used with Laravel Vapor, which is a serverless deployment platform for Laravel applications. Here are the steps to use Octane with Laravel Vapor:
-
Create a new Laravel Vapor project with
laravel/vapor
or update an existing one by adding the Octane dependencylaravel/octane
to yourcomposer.json
file. Here’s an example:"require": { "php": "^7.4|^8.0", "laravel/vapor": "^3.0", "laravel/octane": "^1.0" },
-
Install the dependencies by running the
composer update
command. -
Create an
octane.php
configuration file in the root directory of your Laravel application. This file will contain the Octane configuration options. Here’s an example:<?php return [ 'serve_static' => true, 'workers' => 4, 'maximum_lifetime' => 0, 'watch' => ['app', 'config', 'routes'], 'persistent_connections' => true, ];
This configuration will serve static files, use 4 workers, and enable persistent connections.
-
Update your
serverless.yml
file to include the Octane runtime. Here’s an example:provider: name: aws runtime: provided.al2 environment: APP_ENV: production APP_KEY: ${ssm:/vapor/app-key} APP_STORAGE: /tmp VIEW_COMPILED_PATH: /tmp SESSION_DRIVER: array LOG_CHANNEL: stderr VAPOR_ARTIFACT: ${vapor:artifact} layers: - ${vapor:php-74-fpm} - ${vapor:octane}
This configuration will include the Octane runtime layer.
-
Deploy your application to Laravel Vapor using the
vapor deploy
command. -
Test your application by accessing it through the Vapor-generated URL.
That’s it! Your Laravel application is now running on Octane with Laravel Vapor. Octane will improve the performance and efficiency of your application, allowing it to handle more requests with fewer resources.
Benchmark
If we examine the performance metrics of a Vapor project deployed on the Amazon’s us-west-1 region, we can observe some noteworthy statistics. In this particular instance, the Vapor application has been configured with 1024 MB of RAM and an RDS MySQL instance (db.t2.micro) with 1 VCPU and 1Gib RAM.
To further investigate the performance gains achieved by using Octane, let’s consider an API endpoint that retrieves a user from the database. Remarkably, this endpoint exhibits a speed increase of 7 times and utilizes 44% less memory with Octane enabled.
# Before Vapor's Octane integration
Request Duration: 39.40 ms, Memory Used: 169 MB
Request Duration: 40.20 ms, Memory Used: 169 MB
Request Duration: 37.71 ms, Memory Used: 169 MB
Request Duration: 42.16 ms, Memory Used: 169 MB
Request Duration: 40.60 ms, Memory Used: 169 MB
Request Duration: 45.75 ms, Memory Used: 169 MB
# After Vapor's Octane integration
Request Duration: 6.78 ms, Memory Used: 112 MB
Request Duration: 6.64 ms, Memory Used: 112 MB
Request Duration: 6.67 ms, Memory Used: 112 MB
Request Duration: 6.38 ms, Memory Used: 112 MB
Request Duration: 6.75 ms, Memory Used: 112 MB
Request Duration: 6.47 ms, Memory Used: 112 MB
Moving on, we can now analyze the performance of a “login” route that renders a static template. By utilizing Octane, this particular endpoint showcases an impressive speed increase of almost 3 times and consumes 35% less memory compared to the standard approach.
Request Duration: 11.32 ms, Memory Used: 165 MB
Request Duration: 11.35 ms, Memory Used: 165 MB
Request Duration: 11.29 ms, Memory Used: 165 MB
Request Duration: 11.29 ms, Memory Used: 165 MB
Request Duration: 11.36 ms, Memory Used: 165 MB
Request Duration: 11.43 ms, Memory Used: 165 MB
# After Vapor's Octane integration
Request Duration: 4.89 ms, Memory Used: 108 MB
Request Duration: 4.89 ms, Memory Used: 108 MB
Request Duration: 4.83 ms, Memory Used: 108 MB
Request Duration: 4.66 ms, Memory Used: 108 MB
Request Duration: 4.79 ms, Memory Used: 108 MB
Request Duration: 4.91 ms, Memory Used: 108 MB
By utilizing Octane, you’ll notice a reduction in both request duration and memory usage. Moreover, as AWS employs 1ms billing granularity for Lambda, using this approach for your HTTP function will result in lower costs.