Working With Octane - Some Common Pit Falls

I am developing a new REST API for a client that wants to start separating his application into smaller bits. His current application has multiple bottle necks that are beginning to affect his customers. One of these bottlenecks is traffic load. Currently an excess of 5000 users may connect sanctimoniously and the servers are beginning to time out and drop the customers. Multiple solutions to this issue were suggested and the solution chosen, was using Octane with Swoole on AWS.

Now Octane was officially released with Laravel on May 12th 2021. So at this point it is less than a year old. Currently there are about 300 projects that use Octane including ours. Sometimes my client will ask a question and I won't know the answer. But that is okay, because the documentation for Octane is beautiful. My client doesn't like when I don't have an answer, so I will have to reevaluate how I handle those situations. But I digress. These are the unknowns that I have faced that can be easily communicated.

Octane loads the application into memory once through the CLI. This means that php commands like phpinfo() are run in the CLI. Certain php commands like phpinfo() when run in the CLI act differently than if called from the server. Specifically phpinfo() called from the CLI will return data that has been stripped of markup. This will look like a jumbled mess unless you parse the data. Something simple like this should work, but perhaps there is a better solution that has yet to be found.

    phpinfo();
    return response('')->withHeaders(['content-type' => 'text/plain']);

Next, some of the php run time variables will be affected. max_input_time will default to max_execution_time and max_execution_time will default to -1 or unlimited. To set the max_execution_time we will need to set the max_execution_time in the config/octane.php file. It should look like this:

    /*
    |--------------------------------------------------------------------------
    | Maximum Execution Time
    |--------------------------------------------------------------------------
    |
    | The following setting configures the maximum execution time for requests
    | being handled by Octane. You may set this value to 0 to indicate that
    | there isn't a specific time limit on Octane request execution time.
    |
    */

    'max_execution_time' => 1800,

Because Octane loads the application all at once, file changes in development may not be recognized. Luckily Laravel has some great documentation on that and how to restart Octane when files change.

Swoole comes with Sail, so if you are developing with Sail you will have Swoole. However the documentation suggest launching Octane with Swoole by editing the supervisord.conf file to include the --server=swoole command rather than changing the 'server' => env('OCTANE_SERVER', 'roadrunner'), variable in the config/octane.php file. Not sure why, seems a bit messy. I have yet to mess around with this.

As this project continues I know I will be facing memory leaks and dependency injection, but I have not gotten there yet. I look forward to figuring out how to configure proxy pass throughs with a load balancer to the Swoole server. Managing concurrent php scripts was not something many php developers thought they would ever do but here I am, figuring it out. Like... Comment... Hire me!