This is a really great development for PHP. A bit more background on this for those not familiar with Zend Optimizer+ and PHP. Zend Optimizer+ is an opcode cache, and using an opcode cache greatly improves the performance of PHP. The improvement is so significant, that it's generally not practical to run PHP without using an opcode cache.
Despite an opcode cache generally being necessary to use PHP at scale, one has never been included in the core distribution. There has often been discussion about including APC (another opcode cache) in the core. A suggestion [1] to ship APC with PHP 5.5 was proposed recently, and after some discussion, an alternative was proposed [2]: Zend would open source Zend Optimizer+, and it would be included in PHP 5.5.
No definite decision has been made yet on whether Zend Optimizer+ will make it into 5.5 (or the next release), but the consensus so far seems to be that it will. For more information, see https://wiki.php.net/rfc/optimizerplus
For those of us who have never heard of it, Zend Optimizer+ speeds up PHP execution by opcode caching and optimization. It stores precompiled script bytecode in shared memory. This eliminates the stages of reading code from the disk and compiling it on future access. For further performance improvements, the stored bytecode is optimized for faster execution.
I was testing it the other day in anticipation of this happening and it really does seem about 10% faster than APC.
APC is essentially doomed now at this point.
But optimizer+ does not have a user cache and cannot delete individual files from the cache, it's an all or nothing reset if you don't want to use file stat. There is no control panel though you can fashion one from the statistics function.
Also in my tests I could not get file stat to actually turn off despite the setting but I'll try the open source version.
Isn't APC being integrated into PHP6? Also, now that they can see the source, the APC authors should be able to see where they can further optimise their code.
That was the plan - about four years ago before PHP6 went defunct. Whilst APC works well (I use it currently everywhere in production) - having a solution baked into the core can only be a good thing
For one, the cache will now finally keep inline with the PHP version itself, unlike APC which historically has been behind PHP releases themselves by several months at times.
Keen to get some time to compile this and swap out APC for Optimizer+ on some production boxes.
There are only two or possible three core contributors to APC these days and based on the serious problems with the newest apc dev (they even had to recall a beta) and the discussion on php internals they are likely to focus on optimizer+ instead.
Or read the source and see how it can be broken from a security perspective.
VMware and windows source code leaks in the past have had the effect of "pant shitting" for their former clients in case there is a whopping great big hole in them somewhere. The same is true for this.
Does Zend Optimize work in FastCGI mode? A problem with APC is that each FastCGI worker has it's own cache. I've been trying xcache with PHP FastCGI + nginx and that seems to work well with a shared cache.
That's not correct. APC under PHP-FPM will used a shared opcode cache between PHP child workers, maybe that wasn't the case in the past - but it's been the behaviour I have seen since PHP 5.2 at least. In any case, Optimizer+ is PHP-FPM aware.
Try using HipHop before using the word "simple." Take it from me, as someone who's been playing with it inside of the last 72 hours, it's not an instant plug-in option, and it's absolutely not simple. You're compiling PHP scripts to C++, and if you use any non-standard modules, you're going to be in for some fun.
This option is simple: it's a plug-in module, just like APC, and it requires very little setup or configuration.
If you're going from using nothing to using Zend Optimizer+, you should be blown away by the difference it makes.
At what sort of scale do you really need to switch from php to hip hop?
Honestly, I think that's a bit of a "how long is a piece of string" question. First step is to do zero scaling. As users come on board and you start hitting performance issues, work out where your problems lie - the database or filesystem rather than your code - and optimize for that.
Let's not forget the classic one either: your server might just be underpowered or lacking in RAM.
Once you get into significant numbers of users or usage, it'll quickly become apparent where the bottlenecks lie, and you should optimize as appropriate.
So going back to your question: when PHP becomes the bottleneck.
HipHop works with a certain subset of PHP, whereas Zend Optimizer+ / APC / what-have-you works with it all.
In addition switching to HipHop is far more involved than optimizer modules like this.
In my experience (back in the dreary days when I did PHP stuff) installing APC took just one apt-get and a restart of the web server for instant gains.
As mentioned elsewhere in the thread, hiphop is a name of a project, its not just a php-to-c++ compiler.
hphp was a program built from hiphop that compiled php to c++. This is being completely ripped out of hiphop.
hhvm is also built from the hiphop source. It is a JIT for php, and currently the main focus of the hiphop project.
The rest is still of course true, you cant just switch to hiphop it supports an incomplete set of php which is enough for facebook, but not the average library that you want to import via composer(also doesnt support composer, due to no namespaces yet).
Despite an opcode cache generally being necessary to use PHP at scale, one has never been included in the core distribution. There has often been discussion about including APC (another opcode cache) in the core. A suggestion [1] to ship APC with PHP 5.5 was proposed recently, and after some discussion, an alternative was proposed [2]: Zend would open source Zend Optimizer+, and it would be included in PHP 5.5.
No definite decision has been made yet on whether Zend Optimizer+ will make it into 5.5 (or the next release), but the consensus so far seems to be that it will. For more information, see https://wiki.php.net/rfc/optimizerplus
[1] http://marc.info/?l=php-internals&m=135909498705904&...
[2] http://marc.info/?l=php-internals&m=135913119321197&...