Zend Optimizer+ now open-source on Github(github.com)
github.com
Zend Optimizer+ now open-source on Github
https://github.com/zend-dev/ZendOptimizerPlus/
9 comments
I wrote a small blog post covering the basics. Starts with explaining opcaches, talks about APC and Optimizer+ and has as how to install. Perfect for starters http://www.intracto.com/blog/testdriving-zend-optimizer
Any background on what the difference is between this, and the other op code caches already on the market?
Yes,
See Alternatives --> Benchmarks
https://wiki.php.net/rfc/optimizerplus
HF!
What settings were used on the benchmark?
This was on the market for a long time as a binary. Now you can read the source and see how it works
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.
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.
You know the language itself is open-source, right? this is like a drop in the ocean
And run it without the zend manager which was required previously.
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.
See http://en.wikipedia.org/wiki/List_of_PHP_accelerators#Zend_O...
See http://en.wikipedia.org/wiki/List_of_PHP_accelerators#Zend_O...
Why not simply using hiphop-php ? This is what empowers facebook and seem pretty neat https://github.com/facebook/hiphop-php
Why not simply using hiphop-php ?
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.
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.
What version are you using? HHVM (with JIT) is the successor to HPHPc (the version that has the C++ intermediate stage), and is faster. See http://www.facebook.com/note.php?note_id=10150415177928920
I was playing with HHVM, given quite how much FB emphasize not to even try with HPHPc ;-)
At what sort of scale do you really need to switch from php to hip hop?
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.
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.
The example code made me smile
function f ($a, $k)
var_dump($hit);
function f ($a, $k)
var_dump($hit);
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.
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.
Except it is not that easy. PHP magic is not supported, they are usually a version or two behind, and not all modules are supported.
Adding the opcode cache to core will help get more eyes on the code. This should have happened sooner.
Adding the opcode cache to core will help get more eyes on the code. This should have happened sooner.
"Simply using" and "hiphop"? An opcode cache is used "simply", whereas a php-to-c++ compiler is not.
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).
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).
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.
[edit] According to the RFC to include Optimizer+ in the PHP core, it does work in fpm mode. https://wiki.php.net/rfc/optimizerplus
[edit] According to the RFC to include Optimizer+ in the PHP core, it does work in fpm mode. https://wiki.php.net/rfc/optimizerplus
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.
you mean php-fpm ? apc + php-fpm should place nice together if configured correctly.
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
[1] http://marc.info/?l=php-internals&m=135909498705904&...
[2] http://marc.info/?l=php-internals&m=135913119321197&...
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&...
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.
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.
Bit of a stretch to consider it doomed, imo.
Bit of a stretch to consider it doomed, imo.
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.
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.
For those that want to compare settings to other opcode caches:
directives for php.ini http://files.zend.com/help/Zend-Server/content/zendoptimizer...
functions (though there are a couple of undocumented minor ones) http://files.zend.com/help/Zend-Server/content/zend_optimize...
directives for php.ini http://files.zend.com/help/Zend-Server/content/zendoptimizer...
functions (though there are a couple of undocumented minor ones) http://files.zend.com/help/Zend-Server/content/zend_optimize...
Can anyone see if this supports running Zend encoded programs? I'm not familiar enough with how it works to know if this is enough to run them.
We have to use Zend's idiotic binary-only shim to run a Zend encoded PHP program and it'd be nice to replace it.
We have to use Zend's idiotic binary-only shim to run a Zend encoded PHP program and it'd be nice to replace it.
No, you need to use the zend guard loader extension for that :
http://www.zend.com/fr/products/guard/downloads