Keep bootstrap in process

[ryansunxl]

No description provided.

[thomas-kl1]

Hello @ryansunxl

I don't see the benefit of sharing the bootstrap, the bootstrap is needed to run the application, so when a new request is going to beusing the same instance to run any application by request is going to be handled, the process has to wait for the first execution of the bootstrap instance to complete, isn't it?

[ryansunxl]

The part before bootstrap is very small (< 10ms), if we don't share bootstrap, then we are not really sharing much.

the process has to wait for the first execution of the bootstrap instance to complete

I'm not sure what you were referring to, my understanding is the bootstrap instance will be initialized once in the worker and shared for the future requests and handled in different threads if they are concurrent requests
php/frankenphp#1486 (reply in thread)
there might be some cleanup process needed for the bootstrap after each request though.

[thomas-kl1]

that's the main issue with Magento architecture, see:

$bootstrap->run($app);

The bootstrap run the application, so while the 'run' process is not completed, any thread that use the shared instance of bootstrap, has to wait for the application run to be completed, so you can't benefit of concurrent run.

I agree it would be better to share what could be, that's why I think it could be interesting to check how to exploit \Magento\Framework\ObjectManager\Resetter\Resetter::_resetState for our purpose.
This service allows to reset the state of any service that implements the ResetAfterRequestInterface interface (like repositories).

So maybe it would be better to write our own bootstrap so we can handle better the application instances.

I know that with Adobe Commerce you have the following module : ApplicationServer, that's exactly do what we are looking for (it uses the swoole extendson). It's intended for graphql area only by default, see: https://experienceleague.adobe.com/en/docs/commerce-operations/performance-best-practices/concepts/application-server

However it could be interseting to mimic how the objectManager state can be reset after each request (so we don't have to create a new instance of application for every run).
In the application server module, the cli allows to setup the area, so I guess it could be possible to use the frontend instead of graphql 👀

Sadly I can't share any code because the AdobeCommerce license does not allows it.

[ryansunxl]

$bootstrap->run($app);

The bootstrap run the application, so while the 'run' process is not completed, any thread that use this shared the instance of bootstrap has to wait for the application run to be completed, so you can't benefit of concurrent run.

this is true regardless you share bootstrap or not.

based on this, https://frankenphp.dev/docs/performance/#number-of-threads-and-workers, I assume it is 1 worker per thread in frankenphp, so as long as a thread is still handling request, frankenphp will fetch the next available thread for the next incoming request.

[thomas-kl1]

@ryansunxl you are right, I was missleaded (I'm more familiar with reactphp and mixed their architecture in my mind 🤪).
So yes after re-reading your suggested changes, it makes perfectly sense now 😅