Integrating Zend Optimizer+ into the PHP distribution

• Version: 0.62
• Date: 2013-01-28
• Author: Zeev Suraski zeev@php.net
• Status: Under Discussion
• First Published at: http://wiki.php.net/rfc/optimizerplus

This RFC proposes integrating the Zend Optimizer+ component into the Open Source PHP distribution. Optimizer+ is the fastest opcode cache available for PHP, and presently supports PHP 5.2 through 5.5, with public builds available for PHP 5.2 through 5.4. It was originally developed in 1998 and was the first opcode cache available for PHP.

Presently, Optimizer+ is a closed-source, yet free-for-use component. As a part of implementing this RFC - Zend will make the source code of Optimizer+ available under the PHP License, so that it can become an integrated part of PHP with no strings attached. Once that happens, community contribution would be welcome exactly like it is with any other PHP component, and the component will be governed by the exact same processes (RFC et. al) that are employed by the PHP community.

There’s one key alternative available for Optimizer+ - namely, APC. While architecturally similar, there are several pros and cons for choosing each of these components.

1. Performance. Zend Optimizer+ has a consistent performance edge over APC, which, depending on the code, can range between 5 and 20% in terms of requests/second. See Benchmarks section below.
2. Availability for new PHP versions. Optimizer+ is typically fully compatible with PHP releases even before they come out; While this advantage was rarely realized because of the closed-source nature of the component, once open-source, both Zend and the community will help ensure that it’s always fully compatible with every element of the PHP language, avoiding any lags.
3. Reliability. Optimizer+ has optional corruption detection capabilities that can prevent a server-wide crash in case of data corruption (e.g. from a faulty implementation of a PHP function in C).
4. Better compatibility. We strived to make Optimizer+ work with any and all constructs supported by PHP, in exactly the same way they’d behave without it.

1. Has a data caching API. APC has a data caching API which Optimizer+ does not have.
2. APC can reclaim memory of old invalidated scripts. APC uses a memory manager and can reclaim memory associated with a script that is no longer in use; Optimizer+ works differently, and marks such memory as ‘dirty’, but never actually reclaims it. Once the dirty percentage climbs above a configurable threshold - Optimizer+ restarts itself. Note that this behavior has both stability advantages and disadvantages.
3. APC supports ZTS mode, while Optimizer+ presently does not. Note that this *only* effects Windows deployments that use PHP as a web server plugin. Non-Windows or FastCGI-based deployments are unaffected.

All tests were done with the latest source tree of PHP 5.5.0 as of Jan 28 2013. We've tested plain PHP, APC 3.1.5-dev, Optimizer+ vanilla and Optimizer+ configured for maximum performance. All tests were done on the same hardware, using PHP in FastCGI mode with 4 worker processes. We've tested numerous applications, both procedural and object oriented.

The results are available as a Google Spreadsheet:

http://bit.ly/116BnnB

We can relatively easily work out the disadvantages of Optimizer+ and go with it. Pierre Joye already volunteered to help with implementing ZTS mode when the source becomes available; We could cooperate with the community to implement a different memory-reclaiming strategy if we ever choose to. In terms of a data caching API, there appears to be consensus that a userland data-caching API should be a separate component independently of any other decision.

1. As the code becomes available, put it in PECL.
2. Once the cleanup / initial improvements are done and everything is working & stable - bundle in PHP and move to ext/.
3. Long term, evaluate whether it makes sense to further integrate right into Zend/.

If the RFC gets approved, one open question is whether or not we should aim for integrating Optimizer+ into the PHP 5.5.0 release. While integrating Optimizer+ could probably be done fairly quickly and without greatly delaying PHP 5.5.0’s timeline, it may require a 1-2 month delay. The question on the table is whether most users would prefer a slightly later release with an out-of-the-box working opcode cache, or a slightly earlier release without a compatible opcode cache available for several additional months. It should be noted that if we don’t integrate it in 5.5.0, based on the current timelines and versioning rules, the integration won’t happen before late 2014.

• Integrate Optimizer+ into PHP 5.5.0, allow up to 2 months delay
• Integrate Optimizer+ into PHP, but don’t delay 5.5.0 for it
• Don’t integrate Optimizer+ to PHP, provide it as an optional component in PECL only

• 0.5 - Initial draft
• 0.6 - Added benchmarks
• 0.61 - Added clarification regarding ZTS
• 0.62 - Fixed alignment of this ChangeLog list