Re: [PHP-DEV] FPM: Three-Phase running idea for faster frameworks
Hi, On Fri, Apr 9, 2021 at 5:48 PM Mohammad Eftekhari wrote: > Hi and thanks for the latest great features. > > > Idea visualized: > > https://drive.google.com/file/d/1twuCTk2ssNl5damTydP-aOmOeJ5hWr9r/view?usp=sharing > > This is an idea and it's simple on the paper: *To run the requests coming > to PHP Frameworks in three phases. * > > > Let's say FPM pool child processes can run PHP instances in two-phase: > > >- > >Initialization Phase: It runs an instance of our PHP code with no >request information given. The running PHP code is interrupted by some > kind >of input mechanism which is put deliberately by the developer into the >code. FPM will keep this process on RAM waiting for a request to come > in. > This is basically what was drafted in https://github.com/php/php-src/pull/6772 . I would recommend you to read that PR discussion for details. To sum it up, the tricky part is the implementation as it has to work with all PM's and reload. Most likely we will need to introduce event (epoll on Linux) based loop in the child accepting to be able to properly clean it up. In addition a new request stage will be likely needed and then sorting all the possible edge cases out. Regards Jakub
Re: [PHP-DEV] FPM: Three-Phase running idea for faster frameworks
On 09.04.21 20:22, André Hänsel wrote: Have you tried Roadrunner? I think your design is quite similar (identical?) to what Roadrunner does, only that your worker pool is managed by FPM instead of Roadrunner and that the worker exits after serving one request - which you *can* do with Roadrunner, but it's not recommended. Also, since OP mentioned Laravel, https://github.com/laravel/octane/ has been made public recently. It was announced on the recent Laracon. There's no official release yet though development seems in super-full-force mode and it supports Swoole and RoadRunner. I think they're aiming for the "killer app" (well, framework) here. - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
RE: [PHP-DEV] FPM: Three-Phase running idea for faster frameworks
Have you tried Roadrunner? I think your design is quite similar (identical?) to what Roadrunner does, only that your worker pool is managed by FPM instead of Roadrunner and that the worker exits after serving one request - which you *can* do with Roadrunner, but it's not recommended. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] FPM: Three-Phase running idea for faster frameworks
Hey, I have seen this a while ago and it looks promising, however, I do have my fair share of concerns, namely: 1. We should be able to define some sort of TTL. What happens if no request comes for over an hour? Albeit this is *really* unlikely. 2. Why not implement a mechanism similar to `fork` for these new requests? So that we duplicate the memory of the process and are able to spawn new instances way faster. 3. How many instances will be kept in (I suppose) a pool for answering the requests? Regarding database connections, almost all adapters support some form of connection pooling, so the example you mention about a database connection is a bit obsolete in my opinion. Furthermore, how will we deal with database timeouts, resource exhaustion, and many other problems that might arise when stalling certain processes for too long? Just to see what we should do about the aforementioned issues, I propose that you create some sort of a basic implementation at first, so that benchmarks can at least show us how much of a difference this makes. As far as I can see, the difference will be negligible since most modern frameworks do allow you to generate PHP files, which get pre-compiled by OPCache, and thus already give amazing performance. Also, extensions like APCu go unnoticed and already greatly help storing e.g. pre-compiled routes, if you do not want to generate PHP files. For now, this will require some more discussion. Kind regards, Harm Smits
