Question 182: Rasmus didn’t like async idea and he suggested to use queues and put hard works in other workers. What do you think about it?
We're talking about 2 separate things here, the ReactPHP way is not meant to be a replacement for workers to execute long-running tasks. It's meant to be a more efficient way to use your CPU and RAM resources even for very small requests by not blocking the process when doing I/O. Using a workers and queues for long-running tasks in the context of a ReactPHP app is also the recommended approach, do what Rasmus said!!
Question 179 If you want async, why not just use node? ReactPHP seems a very complicated way to achieve the same that node does
The question is, why not? IMHO it's fun and exciting to push the limits of a language. The fact that this hasn't been traditionally done by PHP doesn't mean it can't or shouldn't be tried or done. By thinking this way, Javascript would have never made it to the backends and become Node, because Javascript was never meant to be that kind of language. Fortunately, some folks thought this could be an interesting thing to try :)
For me it's a matter of taste. If you saw the basic Hello World example that Enrico showed in his talk you will see that they're very similar and they both rely on the same Event Loop pattern.
For me though, I like the fact that ReactPHP is written in pure PHP rather than a C extension, makes it easier to test, deploy, debug and contribute back to. I'm not a huge fan of php extensions these days
Good old memory_get_usage to track and hunt them down. Knowing how PHP manages its memory can help you quite a lot in quickly spotting the leaks (hint: it's almost always a circular memory reference that's not being cleaned up after every request!)
Answered in #179 above
Question 176 I don't get the difference between this and a worker listening to a queue, can you explain it?
You could definitely use ReactPHP process to be a worker listening to a RabbitMQ queue, for example. But with ReactPHP you can also listen (and answer) HTTP requests directly, it's a more generic solution.
Question 172 You said that you are performance junke, but you are still using symfony with most likely a lot of high level packages like doctrine which are slow?
Haha, good question. I am a performance junkie, but not at the cost of making my life more miserable by not using some awesome PHP libraries out there. And to be honest, a well-tuned Doctrine with well-designed entities is fast enough, believe me (hint: don't use "cascade=all")
It doesn't! You need special libraries for what you used to do with the built-in php methods like sleep, file_get_contents or mysql_query. Those are all blocking calls and there's nothing ReactPHP can do for you if you use them, you will block the whole process. Thankfully, the ReactPHP community is growing and you can find async counterparts to those three functions (and others).
Why should it? Isn't it fun? :p
Question 173 Would the new preloading feature in PHP 7.4 avoid all the overhead of loading classes and pair in terms of speed with a ReactPHP HTTP application?
To be honest, I don't know. Looking forward to trying it when 7.4 comes out. However, as I explained during the talk, opcache preloading is not magic, you will need to supply Opcache with your own preloading script.
Question 194 When a database request fails, the Doctrine entity manager usually closes the connection. Since they are all sharing the same $db variable, how do you deal with that?
PHP-PM takes care of this for you in the Symfony bootstrap. It clears or resets the entity manager after every request.
For me it's microservices, it suits very well the REST API approach, but it should support any other type of workload too!
Question 185 Because php do not support async functionality due to obvious reasons, If you need coroutines or multi threads why just don’t pick suited languages like python, java, kotlin, nodejs etc...
It's not that PHP does not support async per-se, it's some IO functions built in the PHP core that don't. But again, I think it's nice to be able to stay with with the same language you're already familiar with. Facebook even made a PHP compiler and interpreter (HipHop and later HipHop VM) to avoid rewriting everything in a new language.
It's a parameter that you can set in the PPM config file.
Question 178 Do you think we can expect some kind of native async I/O and native event loop support on php
I haven't seen anything yet on the internals list yet, not sure what will be the approach (if any, although it was mentioned by Zeev Suraski as one of the key points that PHP 8 should aim for)
Question 187 Doesn't the overhead of callable functions for async lower the performance boost gained on boot?
Nice question. Maybe, I haven't played with a pure async ReactPHP app to be able to answer that. PHP-PM allows me to keep a bit of both worlds.
Question 199 How does reactPHP scale when there are many requests in comparison with having many fpm workers? Being fast is great but if you are only fast for 5 people its not worth much.
Good point. This is one of the areas where PHP-PM should perform a bit better when there's high concurrency. We even have an issue opened for that in our repo, hopefully we can improve that soon!
In a pure ReactPHP async app you only need as many ReactPHP instances as cores on your CPU, so the comparison to FPM is not really equivalent.
In a pure ReactPHP you would start a worker for every CPU core, to maximise the CPU usage. PHP is single threaded, if you only start one worker you're wasting idle CPU time!
Question 181 Do I always need to create a server? Is this possible to use ReactPHP only for some specific cases? As usually I need async process in really rare cases, but async power would be great addition
Don't think of a server as an HTTP server. You can have a ReactPHP worker answering to RabbitMQ calls in an async fashion and use FPM for your normal HTTP requests, for example.
I don't really know yet, PHP8 is still in the very early stages of development
I don't have any yet, but they should perform in a similar way as they both implement the same Event Loop pattern and they're bot written in plain PHP, in contrast to Swoole.
I guess I did already! But blackfire is really hard to implement in a long-running process that can serve multiple http requests. You will need to manually instrument your code, quite a bit more work, but it can be done.
To be honest, I haven't compared both.
Question 191 Who wants to increase speed of theirs applications should also look at the Road Runner. It doesn't have the ReactPHP cons and have a lot of pros.
I'll take a look at it, although I like the fact that ReactPHP is written in plain PHP.
You would still need to fetch them and initialise the memory. I believe it might be even slower than using a properly tuned Opcache.
In theory it should be able to open as many workers as available RAM you had. In practice we're seeing some drops in high- concurrency tests, probably due to the poor algorithm to choose the available worker.
Answered above!
Question 192 ReactPHP provides a few adapters for your I/O, what about programming new adapters for your I/O?
Sure thing! You need to build those on top of the Event Loop that ReactPHP provides and using PHP streams. It's a bit scary at first if you're not used to working directly with streams.
Kinda. The good thing is that PHP-PM acts as a master for all those replicas and can manage them at will, much like PHP-FPM does. If you directly use ReactPHP workers how do you allocate requests to those workers? How do you restart them all in an easy way, or restart a worker if it crashes? You would need to properly set up your Nginx or whatever load balancer you had in front of them and also a supervisor process.
Good question. If you consider Promises as part of the language you're not really being coupled to them. It's true though that there's no PSR for Promises as of November 2019, so you need to choose a specific implementation.
I don't think so, PHP has gotten so much faster in recent years that the speed comparison between a properly tuned PHP and a C extension is not as big as it used to be. Twig had a C extension that was deprecated after PHP7 came out, for example.
Not really, the ReactPHP PSR request will be converted to a Symfony Request (if you use Symfony) and then injected to the normal handle method of the Symfony Kernel. Symfony and your application are not even aware that they're talking to PHP-PM instead of the normal FPM setup.
The good thing about the Event Loop pattern is that you don't really need threads or forks to achieve concurrency. It works well with a single thread, much like NodeJS does.
Question 205 Because async in go is like using a inoxsteel knife to cut meat, and php a wooden knife. Be polyglote :D
Actually I am quite versed in JS, Ruby, Python and C. And yeah, maybe, but again, I like to push the limits of what I already know and see where we might end :)
Yes it does! PPM takes care of that.