[RFC] True native async implementations

[jobs-git]

Highlights

🏅 Top 1 performance in synthetic benchmark
⚡ 30,000% faster latency in Laravel

RFC: https://wiki.php.net/rfc/true_async
Source: https://github.com/true-async/php-src/tree/true-async-stable

True Async Author: @EdmondDantes

Interests

There is also quite a bit of interest in true async as the exchanges here https://externals.io/message/129690#129944 and here https://github.com/orgs/true-async/discussions/9

Description

It was demonstrated that PHP-based framework can beat many frameworks with async, see here:

https://www.http-arena.com/leaderboard/#v=composite&res=mem

It should be noted in the past, during techempower benchmark, actix is among the top contenders in web performance, but in httparena, php async framework scored higher with async/coroutine. While php is not entirely a framework, native async/coroutine is a promising potential

In other works, it also demonstrated massive performance improvement in average latency in Laravel from 4000 ms to 13ms for the same workload.

Misconceptions

• Myth 1

  Myth: Native async will mess up ALL of existing synchronous PHP code and projects globally!

  Truth: Actually no, you have to explicitly define a function/class/namespace to have an async property, otherwise all synchronous codes and projects will happily run as usual as if there is no native async.

• Myth 2

  Myth: Great, now I have to think async when coding new project

  Truth: Actually no, just DON'T define your functions/class/namespace as async then you will be happy with your old php self

[wilaak]

Any talented low level computer guys who want to dive balls deep into the Zend engine to incorporate and maintain this forever? Preferably without too much pay? With at least 20 years of professional experience? Oh and also must have watched every single Wookash Podcast episode?

[EdmondDantes]

Hi everyone!

I'd like to make a few comments regarding performance.

The benchmarks you're seeing are synthetic. In other words, they measure how optimized the server implementation itself is. For real-world scenarios, you can look at the Symfony benchmark, where the gains are much smaller. And It's OK.

Yes, the server's own C code consumes only about 3–5% of the resources, which is certainly very nice.
Do coroutines provide a performance boost? Oh yes, absolutely. But that was already well known. The higher the latency, the greater the benefit.

Full docs: https://true-async.github.io/en/docs.html

[ctfang]

Thanks to the author for proposing true_async — this kind of push toward real asynchronous concurrency is genuinely appreciated.

That said, the core team seems increasingly focused on adding small helper functions, while more fundamental gaps remain unaddressed. In the AI era, developers don't need more syntactic sugar to write faster — AI handles the boilerplate. What PHP really needs are more powerful capabilities that unlock broader use cases: built-in async/await, truly usable multi-threading (beyond Fiber and the long-abandoned pthreads), and a production-ready native HTTP server.

PHP is a general-purpose language, not a CMS function library. If there's nothing pressing to work on, perhaps it's worth stepping back with a coffee and thinking about the bigger picture, instead of turning PHP into a WordPress-only utility belt. The world is moving fast — PHP needs to evolve, not just accumulate syntactic sugar.

[ddevsr]

@ctfang, could you help @EdmondDantes finish their RFC?

There has already been some discussion on externals: https://externals.io/message/129690#129944, but it would be helpful to get more feedback and testing from a broader perspective to validate how this would work in practice.

[jobs-git]

@EdmondDantes @ctfang @ddevsr seeing the external discussion, is there a possibility that this enters experimental in 8.x? So it gets refined and bugs fixed prior to production level @ 9.0

[EdmondDantes]

@EdmondDantes @ctfang @ddevsr seeing the external discussion, is there a possibility that this enters experimental in 8.x? So it gets refined and bugs fixed prior to production level @ 9.0

The project is already in a "soft fork" state. In essence, it's an experimental version of PHP 8.6.

However, the project is not officially supported by anyone at the moment.

[ctfang]

@ctfang, @EdmondDantes could you help @EdmondDantes finish their RFC?

There has already been some discussion on externals: https://externals.io/message/129690#129944, but it would be helpful to get more feedback and testing from a broader perspective to validate how this would work in practice.

Thanks for reaching out — I'm happy to help where I can.

That said, I'm not entirely clear on the nature of this branch. Is this an official RFC driven by the core team, or is it a personal initiative? I ask because, to be honest, I'm not very optimistic about the official stance on pushing multi-threading and async forward in PHP.

Looking back, we've seen promising community efforts face serious headwinds. Swoole in particular had strong momentum — it reached production-ready maturity and gained significant adoption — yet instead of merging it into core, Fiber was introduced as an alternative, which effectively capped Swoole's expansion. Because of that, the Composer/PHP SDK ecosystem never really adapted to long-running, memory-resident execution models. The same pattern played out earlier with pthreads.

On a more positive note, I fully agree with the true_async author's perspective: multi-threading does not have to fragment the existing PHP codebase and ecosystem. In fact, I've built a PHP runtime engine in Go that ships with two VM modes alongside a temp_vm mode, all working seamlessly with existing project structures — and they work well. But my implementation is a complete rewrite, discarding the official PHP engine entirely from the ground up. That's precisely why I think true_async is the better path forward: it builds on and remains compatible with the official engine, which gives it a much stronger future.

So before diving in, I'd love to understand: what's different this time? Is there genuine official backing behind this, or is it another community effort likely to hit the same wall?

[ctfang]

@jobs-git @ddevsr @wilaak @EdmondDantes Looking at this from a more pessimistic angle: the official stance has historically been that changes like this would fragment the community and break old projects. To be honest, I find that reasoning baffling.

How many mature, production projects blindly upgrade their language major version? 5%, if that? Is it really worth sacrificing a future-proof feature like multi-threading for the sake of that tiny fraction? Projects that are stable and running don't need to upgrade — and those that do upgrade are explicitly opting in, fully aware of what they're signing up for. The "fragmentation" argument has never made sense to me.

Meanwhile, we've already lost a significant number of PHP developers to Go precisely because PHP couldn't deliver on async and concurrency for real-world use cases. They didn't leave because they wanted to — they left because they had to. And now, with the rise of AI agents, even PHP's long-touted advantage — rapid development speed — is rapidly becoming meaningless. When AI can generate boilerplate in any language in seconds, what's left to keep people here?

If PHP doesn't start taking multi-threading and true async seriously, the question won't be "will this fragment the community?" — it'll be "will there still be a community left to fragment?"

[sorshion]

We could create a 5-year LTS version on the PHP 8.6 branch, assuming it's the last release of the PHP 8.x series. Then PHP 9 can introduce some major BC-breaking changes.

[sorshion]

I agree. PHP core keeps piling on syntactic sugar, which makes little sense in the AI era. Time to focus on what actually matters for PHP.