Why php-swoole will not used in a Laravel ECO System?

[approached]

Hi @ all

Why php-swoole will not used in a Laravel ECO System? Nodejs is very fast and has a event-driven asynchronous way. In php is that not so easy possible with nginx/apache2.

PHP swoole has also a own mysql, redis and worker clients that work Asynchronous. You can improve the performance.

Just check out the benchmark screen.

Package: https://github.com/swoole/swoole-src Benchmark: http://grigorov.website/blog/performance-comparison-php-vs-node-js

Check the use cases: https://www.swoole.co.uk/

[Patryk27]

How would you like to integrate Swoole with the framework itself?

[mfn]

FTR, there's already https://github.com/swooletw/laravel-swoole

What are you asking specifically for?

[approached]

@mfn Yes this package is what i need. But why is that not in a core?

A mysql and redis driver would be also nice... https://github.com/swoole/swoole-src#mysql

[Patryk27]

If it was in the core, everyone using Laravel would have to install the Swoole plugin, which would greatly reduce amount of users using Laravel.

[Lelectrolux]

@approached Because swoole has tradeoff that are not worth the speed bonus in most app.

Laravel is fast enough. When you need those, Varnish and caching can do a lot of what's left.

And the last 1% can use other options (languages/framework).

[mfn]

It's not in core because, as it is right now, this is special case/context/circumstance not relevant to the 99% majority of users of Laravel, simple as that.

Further, from a software design aspect it would feel wrong to have some specific integration in the framework. The framework is expected to be agnostic and work with mod_php, fpm, react, swoole, etc.

If any of those existing adapters have technical problems, I'm sure the authors will come forward and provide specific fixes but as far as I'm concerned that's about as much as integration should happen in my book.

[greenlentil]

Official support for swoole would be great. The bad performance of laravel is a weakness.

[Patryk27]

@greenlentil: Laravel has bad performance according to whom / to which benchmarks?

[aftabnaveed]

I am using Swoole in production for Laravel and it has been great so far. Before I used to have 4 servers to serve my application and now 2 servers are enough. Here are some of the benefits of using an application server such as Swoole or ReactPHP

1. Cut down the boot time. (I know Laravel boot time is only a few milliseconds but it still takes 20 to 40 ms depending on the size of the application especially the service containers). Imagine you have an XML/JSON/ENV config to manage some arbitray fields, keeping that in memory will significantly increase the performance of your application.
2. Swoole/ReactPHP being async they are able to serve more requests and does not wait for the previous request to finish (This is not related to Laravel but still a win)

The application server is one of the major weaknesses of PHP which Swoole and ReactPHP try to solve. This is not a Laravel problem though. However, these frameworks are taking traction and you can see it from the stars here https://github.com/swoole/swoole-src

There is not much needed in Laravel to make it work with those libraries. The scope of a few objects such as User, Session needs to be redefined.

[hubertnnn]

The only support for Swoole that Laravel need is to make sure not to leak global variables and keep request context separated from libraries.
But that is not only for Swoole but for any reusable php-fpm alternative.
By reusable I mean one that will handle multiple requests without clearing memory and restarting the framework.

The main problem is not the framework itself though, but also third party code that need to fulfill the same requirement, and that is much harder and without some strong arguments from core php devs it might never happen.

[Sladewill]

With the release of php 7.4 coming soon and preloading with a new JIT compiler its probably not even necessary to even consider this as the performance gains from that should reduce load times massively. Taylors already mentioned in a post somewhere he wants to implement the preloading at some point.

[aftabnaveed]

With the release of php 7.4 coming soon and preloading with a new JIT compiler its probably not even necessary to even consider this as the performance gains from that should reduce load times massively. Taylors already mentioned in a post somewhere he wants to implement the preloading at some point.

preload is significantly different than having an application server, I don't think the comparison is even relevant here. What if you want to read and keep some initial data in memory? Preload will probably only keep the compiled version of the class. There are many other cool things which can be achieved through an application server.

[hubertnnn]

This form of preloading is already done by opcache.
All you have to do is configure it correctly on production servers.
7.4 will only further improve it, but wont change the overall behavior.

Swoole, React-php and other similar solutions instead will not only compile the files but run them once. When I check using the debugger I see that every laravel request need ~50ms to boot the framework, and that is the time that will be removed from each request by using those servers and have nothing to do with 7.4 preloading.

[mattstauffer]

I'm going to be honest: A bunch of Swoole folks have been going to every possible avenue in the community saying "BUT WHAT ABOUT SWOOLE" and then throwing around un-true statements about Laravel's performance.

I see some reasonable statements being made in here so I'm going to assume there are super reasonable folks in the Swoole world.

If something were to happen in the Swoole-y direction, it would require something like this:

• Here's what Swoole is
• Here's why it's worth taking effort to make Laravel + Swoole work better than it already does
• Here's why these changes have to be in core instead of https://github.com/swooletw/laravel-swoole
• Here are the changes, explicitly, that would need to be made
• If someone were to make those changes in core, here's what it would look like for them to test it
• Here is why the costs of making these changes are worth the benefits they introduce

[jhdxr]

Let me try to explain the idea in another way.

Whenever a request comes, there are certain steps to process:
PHP interpreter compiles the PHP files [1] --> laravel framework boot up [2] --> handling request --> clean up the resources

Opcache, or the preloading coming in PHP 7.4, can help with step 1. The compile only happens at the first request, and it will be cached in the memory for future use.

What we are trying to solve by adapting swoole / reactphp / etc. is step 2. We are proposing the idea that allows the framework to boot once and being re-used in all future requests. To make this happens, we need to make sure we are very careful about all global things. otherwise, we may leak memory, or share something expected between requests. This is why changes in core necessary.

This is not a small change so before some patches, it's good to hear from the maintainers whether this direction is welcome or not.

[hubertnnn]

The issue with the whole swoole/reactphp thing is that we may want support, but we need to find a solution, HOW to do it.

I was thinking about it, and I believe it is in fact quite simple.
The main issue is services leaking between requests, and to solve that we will need to add a third type of service to the container. Here is my proposition:

Currently container has 2 types of services:

• singelton - the same instance is returned every time
• standard - a new instance is returned each time

What we need is a new type of service, lets call it "context-based"
This new service will behave like singelton within a context aka within the same request, but will have separate instances returned for each request.

Implementation would require 3 new methods in container:
public function context($name, $callback): void
public function changeContext($contextId = null): int
public function terminateContext($contextId): void

First method will be used the same way as singelton to simply bind a callback to create your service (partially copied from official docs):

$this->app->context('HelpSpot\API', function ($app) {
    return new HelpSpot\API($app->make('HttpClient'));
});

Second method will do 2 things:
If called without a parameter: $contextId = $this->app->changeContext() will create a new context with a new unique id, switch the internal list of loaded context services to the new empty one and return the context id.
If called with a parameter: $this->app->changeContext($contextId) will switch internal list of loaded context services to existing one that has the specified id and return that id.

Last method will be used to remove a stored list of context services from memory and call terminate method on all relevant services (implementing TerminableInterface?).

With this implementation its possible to not only split global singletons from ones that are request specific, but also to handle multiple requests by a single process even if request processing will be interlacing (coprocessing?) similar to how nginx works.

With this solution all singelton services that are related to current request like Request, Auth, etc. will need to be registered using the new method. Also package developers will need to be encouraged to split their services between those 2 methods as well.

What do you guys think? Will this be enough, or did I miss something?
Also I don't really like the method to be called "context", maybe someone have a better name for it.

[mfn]

lets call it "context-based"

I like the name and the concept. And it reminds me about GraphQL, they introduced exactly the same concept there for similar reason.

[toxmc]

I used https://github.com/toxmc/fast-laravel

[rhzs]

I'm going to be honest: A bunch of Swoole folks have been going to every possible avenue in the community saying "BUT WHAT ABOUT SWOOLE" and then throwing around un-true statements about Laravel's performance.

I see some reasonable statements being made in here so I'm going to assume there are super reasonable folks in the Swoole world.

If something were to happen in the Swoole-y direction, it would require something like this:

* Here's what Swoole is

* Here's why it's worth taking effort to make Laravel + Swoole work better than it already does

* Here's why these changes have to be in core instead of https://github.com/swooletw/laravel-swoole

* Here are the changes, explicitly, that would need to be made

* If someone were to make those changes in core, here's what it would look like for them to test it

* Here is why the costs of making these changes are worth the benefits they introduce

1. There shouldn't be basic introductory what Swoole is. I believe We had enough in this issue.
2. https://github.com/swooletw/laravel-swoole has so many bugs and open tickets, not updated with latest laravel release.
3. We need official support, if the integrating into laravel framework / core is not possible, the "official" support library will be enough.
4. Each Laravel major release has its themes, but I was surprised that the Laravel 8.x did not consider to integrate library like Swoole into its core to gain more performance win.

[mattstauffer]

@rhzs I offered a suggestion to Swoole fans to potentially make themselves heard. You're welcome to disagree with me. However, you may find that, if you keep doing the same thing, you're going to keep getting the same result.

[rhzs]

@rhzs I offered a suggestion to Swoole fans to potentially make themselves heard. You're welcome to disagree with me. However, you may find that, if you keep doing the same thing, you're going to keep getting the same result.

Hi @mattstauffer, I agree with you for being careful integrating certain library, especially into Laravel's core. However, since the 6.x, I don't see huge performance win (difference) in Laravel. My point is not just Swoole, but the Laravel's plan to make 1,000x faster for the upcoming release, regardless the PHP is performing. I've watched and followed Lara conference https://laracon.net/ but there isn't any about benchmark and new tweaking strategy for Laravel that is written in Laravel docs. I know that PHP 8 is coming, but I don't see a lot of performance optimization effort in Laravel core nowadays. CMIIW.

[mattstauffer]

@rhzs FYI, I'm not the one making the decisions. :) I'm just a random community member sharing opinions.

If someone wants to propose adding Swoole, they would do well, IMHO, by writing a proposal like what I suggested above, rather than complaining it's not there or about the current situation.

[joelharkes]

@hubertnnn we are in need of the exact same feature even without swoole

i called it scoped, but context aware would be the same: #2487

[approached]

PHP is dead

[mattstauffer]

:)

[maher1337]

Laravel Octane is the key.

[approached]

Oh well, good job after 1 Year.

But currently i now the next big thing. It improve the performance better than ever.

[joelharkes]

@maher1337 Actually it seems octane doesn't provide any IOC container request scoped instances. which really is an enormous petty.
i wonder when they figure out they will need this.

[maher1337]

@joelharkes it's still in its early stages more will come.

[joelharkes]

It has been added now:
laravel/framework#37521