3 ms·

> There's no real solid support for async/await in PHP, not even in the form Python has for quite a while now. I'll second this. Async/await support in PHP is

> There's no real solid support for async/await in PHP, not even in the form Python has for quite a while now. I'll second this. Async/await support in PHP is at best an ugly hack. I don't know if we'll ever get first-class async/await support since there is no event loop in the PHP runtime, and because of how PHP works (build and teardown on each HTTP request). > And for me, it might be the biggest problem it has right now, which seriously hurts in some applications. What problem are you trying to solve where a lack of async/await would help?

krick 7y ago
I've encountered dozens, maybe hundreds of problems where it was actually something that would matter. Here's one example. Consider you need to process lots of requests, that require making multiple requests that take a long time to finish (like 10-30 seconds) and you need to do it nearly in real-time. Given there's no sane multi-threading in PHP as well, you end up building your own parallelism support, which requires running lots of workers. Now, every of these workers does some pre-processing, makes a requests and waits for multiple damn seconds, to get the result back, make some computations and get to the next job. Consequently, to handle the same number of requests/sec you need much more workers, which has a lot of overhead, which results in needing more servers. Sometimes you can use CURL to just make multiple similar requests in parallel and call it a day, but in practice I rarely could make use of it (consider that service you need to call might require some fucked up protocol, like SOAP, so you best option would be to rewrite SOAP client using CURL with parallel requests, which is not fun at all). At that point you really start thinking some (any?!) other language would be a better fit for the application, but you have tons of very domain-specific business logic written in PHP that you'd need to rewrite for that app, as well as a team of PHP-developers that are not necessarily ready to learn whatever you have in mind, sooo...
- meritt 7y ago
  > to handle the same number of requests/sec you need much more workers, which has a lot of overhead When doing multiprocessing, it's advisable to fork() instead of creating fresh processes (or launching them in containers etc). As long as you preload the necessary libraries/modules in the parent process before the fork, children will reference the same memory in a copy-on-write fashion. It keeps overhead extremely low. This [1] article is for the Unicorn (ruby) webserver but the way it explains forking, signals, and pipes for inter-process control it's absolutely illuminating. These techniques are applicable to any unix-based applications, including php daemons. [1] https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-tricks/ https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-...
  - krick 7y ago
    Thanks, that's a nice idea. Kind of hard to implement in the setup I'm thinking about right now, but, still, that never occurred to me, so this is something to consider. But, of course, it doesn't replace proper async/await. First of all, there are other situations where this solution wouldn't apply. And even in described scenario it isn't ideal. For starters, pre-loading everything before fork is really easier said than done: quite often data you need to fetch depends on the result of request, but just so happens to be very much reusable between multiple jobs. Then, it complicates the code quite a bit, makes to constantly keep in mind across the whole codebase things you wouldn't really want developer to think much about to start with. Additionally, it makes DevOps harder as well: people want to rely on LoadAvg (which is very unreliable metric, but explaining this to people every time is not what makes for a friendly environment) and multiple jobs doing nothing just waiting for I/O to finish sky-rocket it. Then some DevOps tools (you don't necessarily know about because of department communication) try to be smart by relying on loadavg and start actually breaking things.
godman_8 7y ago
It is a hack, but it works well if you follow the rules. We've deployed stable and scalable APIs using PHP(Laravel/Swoole.) We would have loved to use something more fitting like Go but the time to MVP would have been much longer. While not perfect, it's been great to develop with. Using production code, it provides us ~5x rps (over php-fpm+opcache,) lower latency, better efficiency, and better scalability. However, if variables are set outside the event loop they will not update, so we had to add some additional tests to help avoid this.

krick 7y ago

I've encountered dozens, maybe hundreds of problems where it was actually something that would matter. Here's one example. Consider you need to process lots of requests, that require making multiple requests that take a long time to finish (like 10-30 seconds) and you need to do it nearly in real-time. Given there's no sane multi-threading in PHP as well, you end up building your own parallelism support, which requires running lots of workers. Now, every of these workers does some pre-processing, makes a requests and waits for multiple damn seconds, to get the result back, make some computations and get to the next job. Consequently, to handle the same number of requests/sec you need much more workers, which has a lot of overhead, which results in needing more servers. Sometimes you can use CURL to just make multiple similar requests in parallel and call it a day, but in practice I rarely could make use of it (consider that service you need to call might require some fucked up protocol, like SOAP, so you best option would be to rewrite SOAP client using CURL with parallel requests, which is not fun at all). At that point you really start thinking some (any?!) other language would be a better fit for the application, but you have tons of very domain-specific business logic written in PHP that you'd need to rewrite for that app, as well as a team of PHP-developers that are not necessarily ready to learn whatever you have in mind, sooo...

meritt 7y ago
> to handle the same number of requests/sec you need much more workers, which has a lot of overhead When doing multiprocessing, it's advisable to fork() instead of creating fresh processes (or launching them in containers etc). As long as you preload the necessary libraries/modules in the parent process before the fork, children will reference the same memory in a copy-on-write fashion. It keeps overhead extremely low. This [1] article is for the Unicorn (ruby) webserver but the way it explains forking, signals, and pipes for inter-process control it's absolutely illuminating. These techniques are applicable to any unix-based applications, including php daemons. [1] https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-tricks/ https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-...
- krick 7y ago
  Thanks, that's a nice idea. Kind of hard to implement in the setup I'm thinking about right now, but, still, that never occurred to me, so this is something to consider. But, of course, it doesn't replace proper async/await. First of all, there are other situations where this solution wouldn't apply. And even in described scenario it isn't ideal. For starters, pre-loading everything before fork is really easier said than done: quite often data you need to fetch depends on the result of request, but just so happens to be very much reusable between multiple jobs. Then, it complicates the code quite a bit, makes to constantly keep in mind across the whole codebase things you wouldn't really want developer to think much about to start with. Additionally, it makes DevOps harder as well: people want to rely on LoadAvg (which is very unreliable metric, but explaining this to people every time is not what makes for a friendly environment) and multiple jobs doing nothing just waiting for I/O to finish sky-rocket it. Then some DevOps tools (you don't necessarily know about because of department communication) try to be smart by relying on loadavg and start actually breaking things.

godman_8 7y ago

It is a hack, but it works well if you follow the rules. We've deployed stable and scalable APIs using PHP(Laravel/Swoole.) We would have loved to use something more fitting like Go but the time to MVP would have been much longer. While not perfect, it's been great to develop with. Using production code, it provides us ~5x rps (over php-fpm+opcache,) lower latency, better efficiency, and better scalability. However, if variables are set outside the event loop they will not update, so we had to add some additional tests to help avoid this.