Equivalent of ResetInterface from Symphony DI

[Marian-Kechlibar]

Hi! I am starting this discussion based on the following short exchange of messages on the Czech Nette Forum:

https://forum.nette.org/cs/36737-fungovani-nette-ve-worker-modelu-kompatibilita

Basically, @mabar explained to me that in order to use Nette Dependency Injection in a worker model, something like ResetInterface would have to be supported. This is likely a lot of work, but perhaps I could contribute with some observations; I already have some experience with partial resets of the DI from my own testing micro-framework based on Nette Tester, where I switch contexts between users rapidly, plus from some experiments with FrankenPHP / Caddy and behavior of Nette under it.

I put together an experimental Docker-based server with FrankenPHP and I can offer it as a sandbox for experiments, too.

[mabar]

From my perspective, this is a 3 step process on Nette side:

Introduce a repository with DI contracts, containing the interface (let's call it e.g. ResettableService). Repository separate from nette/di will allow:

• compatibility of packages with older nette/di and resettable without hacks
• easier cross-compatibility with identical interface from other frameworks (this would be the only part with optional dependency hacks)

Add support to nette/di:

• method reset() to the Container class
  • reset would go through all already instantiated services (unlike getByType()) that implement ResettableService
  • this should ideally work also for dynamically added services and without option di > export > types enabled
  • for easier debugging, returning list of reseted services would be nice
• include also known resetable interfaces from other frameworks (Symfony, Monolog) to make at least some stateful libs work out of the box. And/or add some way to include these interfaces by configuration.
• I am not sure what to do about indirectly created services (factories) - perhaps we could start with a simple warning (ignorable per-service?) and, if needed, add some interface to hook into them (factories are mostly used for components, which are likely not needed to support and the compatibility work may be done in nette/component-model)
• Call Container->initialize() after reset? Nette starts session here, sets http headers, initializes cookies. Third-party packages may have similar use-cases.

Add support to all Nette packages:

• nette/bootstrap
  • probably the most complicated, it builds DIC based on the current request parameters
  • there must be no chance to mix-up different containers (debug/production, cli/webserver, ...)
  • some way of listing active containers and/or garbage collector for long-inactive containers would be helpful
• tracy/tracy
  • shutdown handler would need some alternative
• nette/application
  • Application - reset requests and presenter
• nette/http
  • Request - is created through RequestFactory and both Request and RequestFactory are replaced in tests and for CLI usage (to support generating links) therefore this may prove to be quite complicated to solve
  • Response - is commonly overriden in tests, adding reset to the IResponse would be helpful for extra safety
  • Session
• nette/security
  • User
  • UserStorage
• nette/caching?
  • MemoryCache could fill server memory fast and currently does not support conditional invalidation and we just have no way to know if the data stored here are safe to store across requests
• nette/routing (and extending classes in nette/application)
  • pretty much everything
• nette/database
  • finishing all transactions
  • Explorer - lastQuery, transactionDepth

It seems doable, but the amount of work is huge. I probably missed half the stuff that needs reset in individual packages, extensive testing would be needed, identifying common pitfalls in Nette apps, support in third party packages... ouch.

Also for the third party packages it would be nice to notify the mostly used vendors and add some tag to packages that are ready for workers, so everyone does not have to do their own research. This feature is mostly beneficial for high throughput apps in which enabling such feature while blindly believing all packages are ready is just too large risk.

[Marian-Kechlibar]

Yeah, this is definitely a moonshot project, and I feel the need to be very careful even discussing it, because not too long ago I unintentionally made @dg angry by communicating in a way that could be interpreted like "hey, do this work for me, thx". That is not my intent at all, I want to express my gratitude towards everyone who powers such a platform like Nette.

So, if we just consider this a brainstorming session ... what made me think in that direction was a recent search for and experience with performance improvements of my own rather big app that is going to be deployed next year for 1000+ clients as an encryption keyserver. I spent quite a lot of time with Xdebug Profiler, cached what I could etc., and arrived at a point where much of the time cost was the systemic overhead of every transaction, esp. around DI Container load. It could be mitigated a bit by using RAM as tmpfs for cache, but certain sluggishness was still there.

At that point, I searched for alternative PHP servers, given that Apache is known not to be the best environment for PHP performance-wise, and I encountered this article from summer of 2024 that looked like a good benchmark:

https://dev.to/dimdev/performance-benchmark-of-php-runtimes-2lmc

And the performance of FrankenPHP with worker threads, which is a relative newcomer in the field, was impressive - on paper, or rather on screen. So I decided to give it a try.

FrankenPHP is still new enough that our experienced sysadmin hasn't heard of it by November 2024, but with Docker, it was relatively straightforward for me to test it. I was able to come up with a working worker.php over a weekend or so, though I failed in my attempt to get Tracy operational. So my testing and measurement was mostly Developer Tools-based.

Measured values improved, but so did user experience. The UI became snappy immediately. The total request-response time went down by 60 or more per cent, for trivial and nontrivial pages alike. Server-side DataTables now load very fast etc. It is really impressive just to see, given that the only change was the change of platform. No extra caching or DB optimizations etc.

Words of caution

My case may be untypical, my code could be just wrong and badly written. Or simply overgrown, sauropod-style. One test case isn't that much to infer from.

Words of meditation

That said, initialization of the Container is a non-trivial operation with costs that may dominate the overall execution time. My own compiled Container is a behemoth PHP file of 280 kB. Parsing of such a class is expensive. Recycling of the already existing memory representation thereof (even a straightforward clone) is orders of magnitude faster and reduces this overhead to not even 1 ms on my machines.

So, potentially, especially in highly performance-sensitive contexts (Zásilkovna before Christmas! I send a lot of packages with books and I can tell that before Christmas, the system becomes somewhat strained), such a feature could be very advantageous to the clients.

Ultimately, this is a question of "where the market will go", and that is fiendishly complicated to tell in advance. Worker-like environment with a lot of paralellization may be just a fad or a marginal phenomenon. In that case, the effort necessary to make Nette DI resettable would be wasted.

But there is also the other possibility of worker-like environments becoming widespread, at which point support for DI reset could become a competitive necessity for the entire framework, and in that case, it would likely have to be implemented later under time pressure, with more bugs introduced during the process.

IDK. Not even Gandalf would attempt to tell the future here, and I am no Gandalf. I can only say that the performance gains look worthwhile from my limited experience, and that it makes sense to at least discuss the topic a bit in advance.

[Marian-Kechlibar]

BTW this is the meat of my current worker - a static handler function.

$handler = static function () use ($container) {
    $container = clone $container;
    $container->removeService('security.user');
    $container->removeService('latte.templateFactory');
    $container->removeService('security.userStorage');
    $container->removeService('session.session');
    $container->removeService('http.response');
    $container->removeService('http.request');
    // Without this, response codes would leak from one response to another
    http_response_code(200);
    $container->addService('http.request', $container->getByType(RequestFactory::class)->fromGlobals());
    // Run Nette app
    try {
        $container->initialize();
        $container->getByType(Application::class)->run();
    } catch (Throwable $e) {
        Debugger::getLogger()->log($e->getMessage(), ILogger::ERROR);
    }
};