autocannon VS octane

Autocannon GitHub Repository

To make things interesting, let’s send some requests to this server with autocannon:

Using autocannon, I did the following script to simulate 500 concurrent connections over 30 seconds:

We then used autocannon to measure the throughput (requests per second) of each runtime server-rendering our React app.

You could also use tools like autocannon to see how many requests/second you can achieve with various methods. : https://github.com/mcollina/autocannon

I used autocannon to test the function at 100 concurrent executions for 30 seconds. I also used Lambda Power Tuning to find the ideal memory configuration, which proved to be 512MB. All the results are available.

Moreover, if your blocking issue is appearing only on heavy load, you can easily test it using the very nice --autocannon CLI param (see it with clinic flame --help) where you can specificy autocannon options to generate some HTTP load on your web service.

I packaged them both with Docker and deployed them to an EC2 instance, each behind an Nginx reverse proxy I setup in docker-compose. I'm currently testing performance using autocannon from my laptop like this: `autocannon -a 5000 -w 10 URL` (5000 requests with 10 workers), and both apps complete in around 40 seconds. The EC2 instance is in Oregon and I'm testing from Toronto.

You can test it by yourself using console.time(). You can use autocannon to stress-test your http server to see what is really the best options.

When I test this with autocannon making three simultaneous requests (autocannon --connections 3 --amount 3 --timeout 10000 --no-progress http://localhost:5678/):

The web server my app uses is not too slow, after load testing with wrk **the RPS on a single 512MB dyno with database queries is 474 requests per second. While running this test, I could still use the app but the response times were higher (400ms-800ms instead of the usual <110ms).

Re Octane, yes it's WIP https://github.com/laravel/octane/pull/764 there were some performance issues found which don't seem to affect non-Laravel apps which is weird/confusing so that's still being looked into. But, soon.

I was hoping that Octane would add support, but the person running the Octane github is one of those people who quickly closes every issue that isn't considered a bug. So no traction is ever built up like on https://github.com/laravel/octane/issues/110 .

Laravel was recently updated to support serverless deployments, alongside the launch of Vapor[1].

Octane[2] is also very exciting. Using Swoole[3] (or another similar driver), Laravel applications can be run entirely in-memory. Early benchmarks showed Octane increased concurrent requests from ~500/sec. to ~6,000/sec.

[1] https://vapor.laravel.com/

[2] https://github.com/laravel/octane

[3] https://openswoole.com/

Another feature of Laravel you might want to take a look at, just became available since the last Laracon. It's called Octane, and it's currently in a beta version, but its potential for optimization, compared to a normal Laravel app, is pretty great. Note that it requires PHP 8.0.

Taylor Otwell already showed a glimpse of Laravel's latest open-source package, Octane, during his Laracon Online talk - but today, the new package is available on GitHub for everyone to beta test.

New 0.7.3 release includes a rule that can check Laravel Octane compatibility of your application. It basically automates the things mentioned in the official docs. You can give it a try now! And let me know what do you think!

Recently the Laravel Octane package was released. It was created to make Laravel with Swoole and RoadRunner more friendly. We are using RoadRunner instead of php-fpm in dev.family for some time now, and we decided to share our experience and to reveal what advantages it has.