Scaling FrankenPHP - more workers vs multiple load-balanced instances? #527
Replies: 2 comments 2 replies
-
I really have no idea, but my guess is that the issue had more to do with some other factor (ram, network bandwidth etc...). Also the article you linked to is surely suffering from the fact that they used 1 vcpu for the many workers. Id want to see them do the same test with 4, 8, 20, 50 vcpus to see if the issue is cpus or worker threads. |
Beta Was this translation helpful? Give feedback.
-
Yes, this makes sense. A single instance (if using https, especially), has to keep track of a lot of things and maintain each thread. Multiple instances can handle all of this independently. I've also noticed that FEWER workers tend to perform better than MORE workers, but I haven't tested it scientifically yet. I imagine there is a point where the overhead in maintaining the workers causes diminishing returns per worker. |
Beta Was this translation helpful? Give feedback.
-
Hi all
Would increasing the FrankenPHP worker count in Laravel Octane increase req/s by (approximately) the same amount as running multiple load-balanced instances? For example, would would a single
--workers=8
instance be roughly equivalent to two--workers=4
instances behind a load-balancer?The reason I ask is that wasn't the case when I experimented with Octane running Swoole. Two load-balanced instances with 4 workers each were able to handle significantly more req/s than a single instance with 8 workers. Which I found quite confusing...
This was also reflected in another user's benchmarks with Octane / Swoole: https://medium.com/@andrew_10845/laravel-octane-benchmarked-e430a43c6b33. You can see from the results that there was virtually no improvement in going from 4 to 8 workers.
Beta Was this translation helpful? Give feedback.
All reactions