Hi Internals,
Since the start of PHP 7, we've seen some amazing performance improvement
version by version as a result of core updates.
Now some of the biggest wins have been implemented (with JIT due for PHP
8), I'd personally love to see support for Async / Await introduced in
PHP's as a core language feature too.
Being able to perform tasks in parallel such as reading or writing to DB,
cache, queues... Would be a massive advantage and the performance gains
from it could be really exciting!
Looking at how Hack has implemented support, this seems like it could be a
great start for a RFC, what does everyone else think?
Here's a link to Hack's implementation for reference:
https://docs.hhvm.com/hack/asynchronous-operations/some-basics
Thoughts welcome from everyone.
Cheers,
Aran
Does this actually fit in with php's execution model of each request
being a separate thread / process? As far as I understand this kind of
async programming is only useful within an event-loop architecture as
used by nodejs for example. There are things that do this for php like
ReactPHP, but it is not how the language usually gets used, at least
now. Making this really useful would probably entail changing the
execution model to one where requests are handled by long running
processes.
Hi Internals,
Since the start of PHP 7, we've seen some amazing performance improvement
version by version as a result of core updates.Now some of the biggest wins have been implemented (with JIT due for PHP
8), I'd personally love to see support for Async / Await introduced in
PHP's as a core language feature too.Being able to perform tasks in parallel such as reading or writing to DB,
cache, queues... Would be a massive advantage and the performance gains
from it could be really exciting!Looking at how Hack has implemented support, this seems like it could be a
great start for a RFC, what does everyone else think?Here's a link to Hack's implementation for reference:
https://docs.hhvm.com/hack/asynchronous-operations/some-basicsThoughts welcome from everyone.
Cheers,
Aran
Does this actually fit in with php's execution model of each request
being a separate thread / process?
I can see this being useful, when AJAX-querying an endpoint that has to do,
in turn, 2 or more API calls or other async jobs to build its response.
(although async HTTP requests are already possible with curl).
— Benjamin
Hi!
Does this actually fit in with php's execution model of each request
being a separate thread / process? As far as I understand this kind of
async programming is only useful within an event-loop architecture as
used by nodejs for example. There are things that do this for php like
We also have functionality in Curl and some DB drivers that could
execute several queries at once, in parallel, and gather the result. Its
essentially the same thing but applied to specific events. It may make
sense to generalize it - i.e. if you had some process like HTTP request
and you wanted to do curl_multi_exec() but in your code - you'd probably
want some way to easily do that... Not sure how to do technical details,
as I didn't think in depth about it, but by itself the concept does not
contradict the PHP execution model...
--
Stas Malyshev
smalyshev@gmail.com
Hi!
Does this actually fit in with php's execution model of each
request
being a separate thread / process? As far as I understand this kind
of
async programming is only useful within an event-loop architecture
as
used by nodejs for example. There are things that do this for php
likeWe also have functionality in Curl and some DB drivers that could
execute several queries at once, in parallel, and gather the result.
Its essentially the same thing but applied to specific events. It may
make sense to generalize it - i.e. if you had some process like HTTP
request and you wanted to docurl_multi_exec()but in your code -
you'd probably want some way to easily do that...
There would be lots of value in a common framework for that. For a user
it would be nice to send curl requests, database queries etc. and
define the continuation routines in a common way, so that those things
can be composed.
Not sure how to do technical details,
as I didn't think in depth about it, but by itself the concept does
not
contradict the PHP execution model...
It is contrary in the sense that hack's approach depends on an event
loop. This has impact on all code written.
Alternative approaches are possible, like a future-based approach
combined with a blocking wait, which gives the control to the user
might fit more into PHP's current model.
johannes
I really like this idea, non-blocking IO via asynchronous operations in
PHP would be amazing.
I am running into an issue right now where I want to listen to several
different socket streams for data. One example of this would be:
Open socket AWait for dataClose socket AOpen socket BWait for dataClose
socket B
This would be so much easier if I could just listen on both in a non-IO
blocking fashion. I would find this immensely useful.
~Judah
Hi Internals,
Since the start of PHP 7, we've seen some amazing performance
improvement
version by version as a result of core updates.Now some of the biggest wins have been implemented (with JIT due for
PHP
8), I'd personally love to see support for Async / Await introduced in
PHP's as a core language feature too.Being able to perform tasks in parallel such as reading or writing to
DB,
cache, queues... Would be a massive advantage and the performance
gains
from it could be really exciting!Looking at how Hack has implemented support, this seems like it could
be a
great start for a RFC, what does everyone else think?Here's a link to Hack's implementation for reference:
https://docs.hhvm.com/hack/asynchronous-operations/some-basicsThoughts welcome from everyone.
Cheers,
Aran
Whilst it'd take work on both the internals and userland sides to
implement, with so much of the web being powered by PHP, having the ability
to even construct pages in parallel could really speed things up.
In the most simplistic way, imagine rendering multiple view components on a
site in parallel (main body content, header, footer).
Being able to fetch each component's data from the DB separately and then
write out the resultant output to a cache mechanism.
Run imports, or perform API tasks asynchronously...
These are the sort of workloads we face regularly. I for one can certainly
see why it was one of the first things Hack added support for when Facebook
released it, and hopefully, we can find a way to do the same for PHP in the
future too.
I really like this idea, non-blocking IO via asynchronous operations in
PHP would be amazing.I am running into an issue right now where I want to listen to several
different socket streams for data. One example of this would be:
- Open socket A
- Wait for data
- Close socket A
- Open socket B
- Wait for data
- Close socket B
This would be so much easier if I could just listen on both in a non-IO
blocking fashion. I would find this immensely useful.~Judah
Hi Internals, Since the start of PHP 7, we've seen some amazing
performance improvement version by version as a result of core updates. Now
some of the biggest wins have been implemented (with JIT due for PHP 8),
I'd personally love to see support for Async / Await introduced in PHP's as
a core language feature too. Being able to perform tasks in parallel such
as reading or writing to DB, cache, queues... Would be a massive advantage
and the performance gains from it could be really exciting! Looking at how
Hack has implemented support, this seems like it could be a great start for
a RFC, what does everyone else think? Here's a link to Hack's
implementation for reference:
https://docs.hhvm.com/hack/asynchronous-operations/some-basics Thoughts
welcome from everyone. Cheers, Aran
A different but valid approach to your concerns is krakjoe/parallel (
https://github.com/krakjoe/parallel/blob/develop/README.md). Unfortunately,
NTS support is lacking, but it would be very good if the internals
collaborated with this project.
El dom., 22 de dic. de 2019 17:59, Aran Reeks cdtreeks@gmail.com escribió:
Hi Internals,
Since the start of PHP 7, we've seen some amazing performance improvement
version by version as a result of core updates.Now some of the biggest wins have been implemented (with JIT due for PHP
8), I'd personally love to see support for Async / Await introduced in
PHP's as a core language feature too.Being able to perform tasks in parallel such as reading or writing to DB,
cache, queues... Would be a massive advantage and the performance gains
from it could be really exciting!Looking at how Hack has implemented support, this seems like it could be a
great start for a RFC, what does everyone else think?Here's a link to Hack's implementation for reference:
https://docs.hhvm.com/hack/asynchronous-operations/some-basicsThoughts welcome from everyone.
Cheers,
Aran