PHP 7 is well on its way. RFCs are being implemented and polished, projects are being tested, libraries upgraded. Extensions are being modified, and the word is spreading. All that remains is getting the shared hosts on the upgrade bandwagon – the arguably most difficult part of improving the global state of PHP. In this article, we’ll take a look at some of the most important PHP 7 related resources and tips you should go through in preparation for the new version.
Nice post Bruno! I am not too sure I’d want to brag my code runs on PHP 7 though. Although it is tempting. LOL!
What interests me the most are the large performance gains and smaller memory footprint per request. That is something almost worth bragging about.
Would you say the performance is so good, a JIT compiler isn’t going to do much more? Or can there still be an improvement in performance with a JIT compiler? I noticed in the benchmarks PHP7 is comparable to HHVM, but what is never mention is if the HHVM JIT compiler is on or not and if not, what are the differences then? If the HHVM JIT is on, oh my. I am impressed.
Ok. I just read one of the articles you linked to and the author said PHP7’s performance is on par to HHVM with the JIT compiler working. Now the question in my mind is, would having a JIT compiler help with performance or with the memory footprint.
It probably would help, yes, to a degree. But I think the focus now deserves shifting from performance to some more pressing matters. At these speeds, it’s almost impossible for PHP to become the bottleneck. But making the built-in server a viable Apache/Nginx replacement - now that’s something I could see as downright revolutionary.
Yes, it’s been on my list for a while, need to check that out again. We’ve had a brief look a long time ago but I definitely want to dive in deeper and deploy something proper on it.
I also read that article. Appserver has come some way since then. Installation was a breeze and I am wrapping my head around how to use the beans, servlets and other services. If you ask me, it is like a very light PHP framework on steroids.
Actually, “on steroids” is the incorrect way to express what Appserver represents. It is more like a lightweight framework that allows PHP to be what it actually needs to be.
Interesting, after Michael Morris’s post here about mark_script_ready() I built a PHP app server. (In my limited tests so far it’s 500% faster than not using the app server on a non-trivial application). Essentially, when you connect to the server via HTTP, Apache/NGIX/whatever all that does is run a minimal script that does nothing except connect to the app server and request the state rather than construct all objects, connect to the database then shutdown.
So far I’ve got great concurrency (it runs a server on each available thread) and maintains persistence so if your code does $num++ each time you visit a page $num goes up without getting reset.
Which basically means, you can do different things at different times, instead of doing it all with each request. As Stefan points out in the video above, with Appserver, you don’t have to run any bootstrapping scripts with each request. You can store such things (and many others) as a servlet, which start running at server startup and stays in memory until the server is stopped or restarted. It is sort of akin to the Tomcat web server for Java, from what I can tell.
With something like that, are you saying that instead of going through the normal steps of installing Apache and then PHP, you would just have one simple install of PHP only? In your mind, how would all of that fall into place from the perspective of shared usage?