On Mon, Jun 25, 2018 at 8:52 PM Larry Garfield <la...@garfieldtech.com> wrote:
> On Monday, June 25, 2018 11:16:31 AM CDT Sara Golemon wrote: > > > > First, I'll admit that there's definitely some of that happening. But > to > > > paraphrase my daughters - "I didn't start it!". In other words - > people > > > are very actively looking for ways to run PHP in a Node-like manner, > and > > > with the shift towards micro-services - I don't think it's a fad. I > > > think we need to go there if we are to stay relevant. > > > > Fair point. I've certainly had discussions with Liz Smith and even > > been on Zend sponsored podcasts discussing ways we might "appify" PHP. > > But, and perhaps I'm just a bit more skeptical of the microservices > > train, I think we should be judicious in our pursuit of the new > > hotness. That's all. Most of my response was centered on what felt > > like a rush. Factoring in that entire paragraph about having a thin > > 7.4 release with a subsequent 8.0 GA alleviates my concerns a great > > deal. > > When we speak of "typical web loads" not getting much benefit here, are we > really talking about CGI-style "reboot every request" type loads rather > than > "IO-bound work"? Because it's been observed many times in the past that > one > of the most expensive parts of a modern PHP app is simply booting up, > initializing all of the services, wiring everything together... and then throwing it away 100 ms later. If a JIT would make it more viable to pre- > start a web process (there are various all-user-space implementations in > the > wild already) so that an incoming request already had a fully booted system > > with container initialized and stuff, that could have a huge impact on web > > loads, even without going all-in on Node-style async. > I thought I'd be given the benefit of doubt regarding having a clue about performance of PHP workloads... :) On point, the initialization cycle isn't radically different with JIT. Initializing the request is pretty similar, as is the stage of loading classes. The current JIT implementation doesn't bring substantial performance gains with most real world apps we tested - as they simply don't seem to spend too much in pure PHP logic (discounting the loading of classes). Of course - your mileage may vary, and it's not outside the realm of possibility that certain apps that are CPU-heavy in either their initilization or execution would benefit - perhaps even greatly - from JIT. It may also depend on the specific CPU and a lot of other factors. When people start testing it in the wild I guess we'll have a better view. What will definitely bring benefit to real world workloads is preloading, which (if we manage to do it) will dramatically reduce the per-request initialization stage. It could bring us much of the benefit of async-IO long running processes without sacrificing the isolation advantages of the traditional PHP execution model. It will likely also play nicely with JIT. But this is floors upon floors of speculation - we'll have to see... Question from the peanut gallery: why would 7.4 need to be a deprecation- > mostly release? Is the concern that it would make merging to the engine > changes in 8.0 harder? Certainly, but even without it - it's going to be hard enough to release 8 with its features within 2-2.5 years. It will be impossible to do it while spending most of that time working on other releases. I don't think people realize just how ambitious these bulletpoints are - to pull off in ~24 months (gross). It took us, IIRC, approximately 18 months from the point we published phpng and until PHP 7.0 was ready - as we focused exclusively on it. We're not in a very different stage with JIT right now, but we're throwing in several other radical improvements with far reaching implications - async and preloading (and that's before others pitched in their ideas). We have finite resources, and honestly, the resources we have that can work on these deliverables are very scarce. We need to choose are battles. Zeev
