In a new post to their site, the PHP.cc (well, Sebastian Bergmann) takes a look at the bytecode caching feature that's included in the latest release of PHP, version 5.5.

PHP is an interpreted language. The default PHP runtime, the one that can be obtained from php.net, compiles PHP sourcecode to an intermediate representation called PHP bytecode which is then executed. A bytecode cache stores this compiled representation of PHP sourcecode in shared memory. This eliminates the need to load and compile sourcecode on each request which leads to a significant increase in performance (up to 70% more requests per second).

He looks some at "the past" of PHP and how it made it up from the world of PHP 4.x to PHP 5.4 and the de-facto bytecode cache before now, APC. With the introduction of PHP 5.5, though, developers have access to an integrated version of the ZendOptimizer+ cache built right into the language. They include a little bit of documentation about how to enable it and how to install it via PECL if it's not already built in.

Chris Jones has a new post to his Oracle blog today talking about the new "opcode" opcode caching that's going to be built into future PHP versions This is the implementation of the Zend Optimizer+ opcode caching in a native language interface. The latest PHP 5.5 snapshots have it included.

The new "opcache" can be seen as substitute for the venerable APC cache, the maintenance of which had become an issue. Note: although opcache is now readily available, there is currently nothing preventing you from using any available (working!) opcode cache in PHP 5.5.

He gives you a quick guide to getting this new opcode caching enabled and compiled into a shiny new download of the PHP 5.5.x branch. You'll need a special command line flag on the compile and to update your php.ini to load the needed shares module. You can also use it if you're on PHP 5.2 or higher either by compiling this source or using this PECL extension.

PHPClasses.org has posted the latest episode of their "Lately in PHP" podcast series - Episode #33, "PHP Innovation Award Winner of 2012".

he PHP Programming Innovation Award Winner of 2012 was announced. An interview with the winner, Karl Holz from Canada, was one of the main topics of the episode 33 of the Lately in PHP podcast conducted by Manuel Lemos and Ernani Joppert. They also discussed the usual batch of PHP topics of interest like Zend Optimizer+ source code that was released, the PHP 5.5 feature freeze and roadmap, as well an article that compares PHP to an Hobbit, as well other languages to Lord Of The Rings story characters.

You can listen to this latest episode either through the in-page player, by downloading the mp3 or you can watch the video of the recording. You can also subscribe to their feed to get this and other episodes as they're released.

Lukas Smith has a new post today about what he sees as an important part of PHP (or really most open source projects) - a predictable release cycle. It centers around the recent proposal to introduce the Zend Optimizer+ into the core and how it seems to be causing a delay with 5.5 (maybe up to 2 months).

What troubles me though is that its being proposed very late in the game for PHP 5.5, therefore causing a likely delay of 5.5 of at least about 2 months in the best case scenario if it were included. The other option of including it in 5.6 does not seem to be as popular at this point. This saddens me quite a bit since I believe that predictable release cycles would carry several advantages

He points out some things that come along with having predicability around the software releases like developers knowing when/if their changes will make it into the next release. It also makes it easier for end users to plan their releases of their own software, knowing when they'll be getting a feature. In this particular case, though, he doesn't quite understand the delay as the Zend Optimizer+ isn't a change to core, it's an addition:

What is even stranger for this case is that we are just talking about an extension here. Its not a language feature, there is no engine level integration. So even if its not added to core, people can easily get Optimizer+ via PECL. So in this case we are not talking about people having to wait another 10-11 months. Don't get me wrong I think getting an opcode cache into core is awesome, but the reality is that shared host users will probably still not have access to it [...] and the rest can still get it, albeit with a bit more effort.

On PHPClasses.org today they've posted the latest episode of their "Lately in PHP" podcast, Episode #32, "Zend Optimizer+ Cache in PHP 5.5 and MySQL 5.6 Performance Improvements".

MySQL 5.6 speed improvements and how it affects PHP applications was one of the main topics discussed by Manuel Lemos and Ernani Joppert on the episode 32 of the Lately in PHP podcast. They also commented on the eventual adoption of the Zend Optimizer+ as the PHP code caching extension that may be shipping with PHP 5.5 as alternative to APC, the implications of this to the PHP community.

They also talk some about the switch of OpenSuSE/Fedora Linux to MariaDB MySQL, TDD in the Zurmo PHP Open Source CRM and using HTML5 animations. You can listen to this latest episode either through the in-page player, by downloading the mp3 directly or watch the video of the recording on YouTbue.

Chris Merrill has written up a case study measuring the load handling abilities of the Zend Optimizer with a default application - in this case, SugarCRM.

This article measures the performance impact of the Zend Optimizer on a real-world processor-bound PHP application (SugarCRM) under load. Our measure of performance is user capacity. We define that as the number of simultaneous users that the system can support while meeting the specified performance criteria. The performance criteria for this test require that all pages load within 6 seconds and no errors are encountered in the application.

The process is broken out into a few different sections including the methodology he used (including the software list, hardware used and configurations of both) and the results/analysis from running the test requests (such as page duration and server process use).

Chris Merrill has written up a case study measuring the load handling abilities of the Zend Optimizer with a default application - in this case, SugarCRM.

This article measures the performance impact of the Zend Optimizer on a real-world processor-bound PHP application (SugarCRM) under load. Our measure of performance is user capacity. We define that as the number of simultaneous users that the system can support while meeting the specified performance criteria. The performance criteria for this test require that all pages load within 6 seconds and no errors are encountered in the application.

The process is broken out into a few different sections including the methodology he used (including the software list, hardware used and configurations of both) and the results/analysis from running the test requests (such as page duration and server process use).