[meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI

There is an integration of Laravel Octane with FrankenPHP.
The results show that FrankenPHP is even quicker than Swoole.

https://blog.laravel.com/octane-frankenphp

FrankenPHP has a known issue about crashes when certain PHP constructs and functions are used within Fibers. I think it would be great to open a separate Drupal core issue that tries to find out if Drupal makes any of those calls within fibers. That could happen independently of this issue, which affects all persistent app servers, not just FrankenPHP. However, I don't have any ideas at the moment on what the best way would be to determine if Drupal triggers any of those FrankenPHP crashes without first solving this issue.

The only child issue and possible way forward is ✨ Use symfony/runtime for less bespoke bootstrap/compatibility with varied runtime environments Active

FrankenPHP official support in Drupal would be awesome, I'll give it a try if I find the time !

Nice write-up and tool to catch shared data https://dev.to/sergiid/getting-symfony-app-ready-for-swoole-roadrunner-a...

Re: #87, that is the issue we need to untangle at #3324241: Provide DIC-friendly, concurrency-safe alternative(s) to `drupal_static()` → . Should we change the parent of that issue to this one? Runtime is one of a few items that need to be addressed. The reference to the ResetInterface in Symfony 7 is excellent and provides us a model to build on instead of rolling our own.

For searchability

Let's add Swoole then also for searchability.

Added an issue to add a Caddyfile to core, used by frankenphp (which is based on caddy), with an rough implementation of the early hints feature that's available thanks to frankenphp (and symfony). We can start by using that in the non-worker mode and once all the issues from this meta are dealt with we can turn on the worker mode of frankenphp to make everything faster without changing much on the infra side.

I don't think enough people are aware of the massive performance boost effect this feature can Drupal!! otherwise it would be done long time ago

There's fresh approach to add the Symfony Runtime's frontend in ✨ CLI entry point in Drupal Core (Dex) Needs review

Re @sinasalek there's long way to clean all static variables before Drupal sites can benefit of pre-bootstrapped kernel

Thanks for the update @standpoint
There has been many attempts do this over the years but non had enough strength to pull through.
I'm thinking about creating a new initiative, raise awareness and gather enough support to tackle this complicated issue.

Symfony supports runtime, which might be a good start. It's suppose to support different runtimes for running symfony
https://symfony.com/doc/current/components/runtime.html

As for static variables. it is possible to workaround it. There are multiple ways to address it. it appears that Swoole can handle it using co-routines
https://www.perplexity.ai/search/I-want-to-EZuTp_oHSmiElEHFpfToow

When I wrote Tome (a static site generator) I wanted the performance to be better than `wget --recursive`, so I added in the ability to handle multiple HTTP requests in one bootstrap. There are still many odd bugs, but here are some overrides I did to reset "state" between each request:

https://git.drupalcode.org/project/tome/-/blob/8.x-1.x/modules/tome_stat...

Might be helpful to future core changes!

That linked code snippet is Exhibit A on why there needs to be an API-level fix for this issue. So many caches/states to reset. And I'm sure they were all hard-fought to discover.

For me #3324241: Provide DIC-friendly, concurrency-safe alternative(s) to `drupal_static()` → could be part of that.

I think focusing on “reset” is the wrong part of the equation. The focus should be on creating a context for static caches to be attached, to that allows for switching or clearing. A request may have such a context and it may be shared (e.g. between sub requests). However it should also be able to exist without a request (e.g. in a long running process).

A long running process might have a memory cache that has changes from another application passed to it through a message bus to make sure it doesn’t use outdated data.

The API that Drupal provides should make it possible for services to easily use the right cache at the right time, that’s likely the hardest part.

Re #99. That makes sense. Static cache is the fastest cache ever. It would be not wise to throw it away. I think the potential performance gain from static cache might be comparable with the one from skipping bootstrap phase. The application needs to have a control on what needs to be reset.

I think #2218651: [meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP, Swoole → is a duplicate of 🌱 [policy] Standardize how we implement in-memory caches Needs work .

Re #99 we could probably add RequestAwareMemoryCache or something like that, it would only be necessary for some caches, not all.

For caches that are unbounded but also don't need request context, we need #1199866: Add an in-memory LRU cache → .

I think this issue has wider scope than 🌱 [policy] Standardize how we implement in-memory caches Needs work . Application state is not only about static caches. There are some other resources that may need to be reset between requests. DB connections, temporary files, open streams, etc. In Spiral framework that process is called finalizing. Finalizers are responsible for cleaning up resources. For instance, logger finalizer will call reset method on Monolog loggers.

Besides resource management there is another challenge. Request aware services. In core.services.yml I counted 47 services that has direct dependency on request_stack and there are many services that has indirect dependency through services like @current_route_match, current_user, datetime.time, etc. In Spiral that implemented with "scoped containers". For each request it creates a scoped container derived from root container with some request specific services.

One more issue to address is stateful Drupal kernel. It has a few of boolean flags (booted, prepared, etc) that needs to be reset after each request.

Sorry wrong issue reference above, edited my comment to correct.