Already got OctoberCMS working with Swoole after some work with https://github.com/scil/LaravelFly running in "Map" mode.
but have only two main issues with current OC code:
the stage at which Execution Context (back-end/front-end) setting happens is very early
See: https://github.com/octobercms/library/blob/master/src/Foundation/Bootstrap/RegisterOctober.php#L40-L50
It is not until System\ServiceProvider is registered that ExecutionContext is actually checked
See:
https://github.com/octobercms/october/blob/master/modules/system/ServiceProvider.php#L73
So why not make that check at that later stage?
This would allow us to run the bootstrapper's code only once, and only register the System ServiceProvider on every new request.
Global vars usage is troublesome. Had a problem where all AJAX widgets were not working and traced it down to the use of global $_POST in post() helper function in:
https://github.com/octobercms/library/blob/master/src/Support/helpers.php#L42-L51
it was always coming back empty. however, request()->post() works for both php-fpm and Swoole.
also LaravelS mentions cannot use global vars like $_POST/$_GET etc: https://github.com/hhxsv5/laravel-s#important-notices
@tamer-hassan I don't really have any idea what you're asking for nor do I have the time to research a bunch of other projects to figure it out either. Try simplifying what you're saying so that I can easily grasp what it is you're trying to do / want me to do about your question.
@LukeTowers Thanks for replying. I will try to explain as briefly as possible:
Swoole is an event-driven asynchronous & concurrent networking communication framework with high performance written only in C for PHP. Since version 2.0, Swoole is also described as a Coroutine-based concurrency library for PHP (Like Golang).
Swoole allegedly performs much better than php-fpm. According to tests here https://laravel-news.com/laravel-swoole , laravel-swoole handles 8717+ requests/sec where php-fpm was only handling 80.9s requests/sec. So you can think of Swoole as something like NodeJS but for PHP, with higher performance.
Now, all these projects mentioned, like FlyLaravel, LaravelS, Laravel-Swoole, aim to integrate Laravel with Swoole to take advantage of its high performance capabilities, replacing php-fpm.
So, with any of these projects, one installs Swoole and enables it as a php extension, starts a nginx server and let it proxy pass connections to the Swoole server.
Finally, to simplify, I would like to be able to allow others who want to try it with OctoberCMS to simply:
vendor/october/rain/src/Foundation/Http/Kernel.php , but rather in app/ directory or similar, like in Laravel for example.~ (no longer needed, with october-fly)$_POST and $_GET in vender/october/rain/src/Support/helpers.php so that the same code works for both Swoole as it does with php-fpm.hope that clears things up
@tamer-hassan how about you submit a PR with the required changes to support Swoole to the https://gitub.com/octobercms/library repository and we can carry on the discussion there?
@LukeTowers PR's submitted, with changes as minimalist as possible.
Moving only the execution-context setting of back-end/front-end to System\ServiceProvider allows Swoole-based projects to work properly when only System\ServiceProvider is configured as a 'providers_in_request' (as in OctoberFly example config ), and everything else booted on worker (kept in memory). I have also tested the changes on php-fpm and it works as expected.
using request() helper instead of Globals $_GET / $_POST fixes issues with Swoole like inability to login, and also lets all AJAX based widgets work. Also tested on php-fpm an it all works as expected.
Also I've simplified OctoberFly itself a bit in 0.0.2, so that no editing of October Http Kernel is needed, while still allowing same code to run with both php-fpm & Swoole.
The performance gains are definitely good so far.
@tamer-hassan I'm thinking that the accompanying plugin should probably live under the octoberrain vendor since we're supporting swoole within the core. Do you have any thoughts on that?
@LukeTowers october-fly requires scil/laravel-fly, which in turn requires ext-swoole.
https://github.com/scil/LaravelFly/blob/master/composer.json#L20
Swoole extension is only available for installation on Linux (via PECL) and mac OS X (via brew).
Right, but I'm suggesting that October-Fly lives under https://github.com/octoberrain/swoole-plugin. That way support for Swoole within October is more of a first class citizen with a more centralized place for maintaining support.
Sounds good. Let's do that!
Is this swoole-plugin still in progress?
Better to ask @tamer-hassan ;)
@Johnzero I'm not opposed to working on it but I don't have any use for it right now nor any funding to work on it.
@LukeTowers - I've been trying to contact you about exactly that :)
I've sent you an email, just fyi
@LukeTowers I would like to continue maintaining october-fly, and there's obviously funding now available (per domstarkey's comment above). What's keeping us from moving forward?
@tamer-hassan trying to coordinate a meeting time with @domstarkey, my life's pretty hectic right now.
the stage at which Execution Context (back-end/front-end) setting happens is very early
Execution context now occurs from a provider and lives inside the container, see https://github.com/octobercms/library/commit/0ae48e9f968bac97614838c14f16be6c619a6ae0
Global vars usage is troublesome. Had a problem where all AJAX widgets were not working and traced it down to the use of global $_POST in post() helper function in:
Request values (GET/POST) are now pulled from the app container, see
https://github.com/octobercms/library/commit/fd839047c2d7757f225a8ed60673ca8a20fe7df4
The header_remove() call has been removed entirely because it did nothing:
https://github.com/octobercms/october/commit/c5bc804d7398522783fbd76b2764f9541747867d
There is no more premature termination of the application thread, no more exit() or die() used:
https://github.com/octobercms/october/commit/5190c8177bbb6531836ad8fa8458111361a35608
That should just about cover it. If there are any other issues with Swoole compatibility we should create a new issue for it and reference this one.
Thanks!
Most helpful comment
@LukeTowers PR's submitted, with changes as minimalist as possible.
Moving only the execution-context setting of back-end/front-end to System\ServiceProvider allows Swoole-based projects to work properly when only System\ServiceProvider is configured as a 'providers_in_request' (as in OctoberFly example config ), and everything else booted on worker (kept in memory). I have also tested the changes on php-fpm and it works as expected.
using request() helper instead of Globals $_GET / $_POST fixes issues with Swoole like inability to login, and also lets all AJAX based widgets work. Also tested on php-fpm an it all works as expected.
Also I've simplified OctoberFly itself a bit in 0.0.2, so that no editing of October Http Kernel is needed, while still allowing same code to run with both php-fpm & Swoole.
The performance gains are definitely good so far.