Hi. >> But for the critical parts of a system that requires optimization of the >> execution duration
If you want to improve performance, you need to optimize SQL queries, not try to execute them in parallel. This can bring down the entire database (like it did today :) ) There are only a few patterns where multiple asynchronous queries can actually be useful. Hedged Requests for example. Question: how often have you seen this pattern in PHP FPM applications? Probably never :) I know it. Right now, there are only two significant PHP frameworks that are ready for stateful execution. And only one of them supports asynchronous stateful execution. This situation is caused by several reasons, and one of them is whether or not the language itself provides support for it. Why is stateful execution the primary environment for async? Because async applications are servers. And FPM is not a client-server application. It's a plugin for a server. For a very long time, PHP was essentially just a plugin for a web server. And a client-server application differs from a plugin in that it starts up and processes data streams while staying in memory. Such a process has far more use cases for async than a process that is born and dies immediately. This is the distinction I’m referring to. As for the issue with frameworks: a project with several tens of thousands of lines of code was adapted for Swoole in 2–3 weeks. It didn’t work perfectly, sometimes it would hang, but to say that it was really difficult… no, it wasn’t. Yes, there is a problem, yes, there are global states in places. But if the code was written with at least some respect for SOLID principles, this can be solved using the Context pattern. And in reality, there isn’t that much work involved, provided the abstractions were written reasonably well. > If you have a report that executes 3 queries and each query averages between > 4 to 5 seconds, If an SQL query takes 3...5 seconds to execute, just find another developer :) Developers of network applications (I’m not talking about PHP) have accumulated a lot of optimization experience over many years of trial and error — everything has long been known. Swoole, for example, has a huge amount of experience, having essentially made the classic R/W worker architecture a standard in its ecosystem. Of course, you might say that there are simple websites for which FPM is sufficient. But over the last two years, even for simple sites, there’s TypeScript — and although its ecosystem may be weaker, the language may be more complex for some people, and its performance slightly worse — it comes with async, WebSockets, and a single language for both frontend and backend out of the box (a killer feature). And this trend is only going to grow stronger. Commercial development of mid-sized projects is the only niche that cannot be lost. These guys need Event-Driven architecture, telemetry, services. And they ask the question: why choose a language that doesn’t support modern technologies. Async is needed specifically for those technologies, not for FPM.
