Accelerating PHP with Zend Opcache (2)

optimizer+ is the first and fastest opcode caching tool for Zend developed closed-source, but free-to-use PHP optimization acceleration components. Now, Zend technology company will optimizer+ under PHP License open source becomes Zend Opcache.

The Zend Opcache provides faster PHP execution through opcode caching and optimization. It stores precompiled script files in shared memory for later use, avoiding the time consuming of reading code from disk and compiling it. It also applies some code optimization patterns to make code execution faster.

1. What is the opcode cache??

When the interpreter finishes parsing the script code, it generates intermediate code that can be run directly, also known as the opcode (Operate code,opcode). The goal of the Opcode cache is to avoid duplication of compilation and reduce CPU and memory overhead. If the performance bottleneck for dynamic content is not CPU and memory, but I/O operations, such as disk I/O overhead from database queries, the performance gains of the opcode cache are very limited. But since the opcode cache can lead to a reduction in CPU and memory overhead, this is always a good thing--in an environmentally friendly manner, you should also minimize consumption. :D

Modern opcode buffers (optimizer+,apc2.0+, others) are stored using shared memory and can be executed directly from the file without the "deserialization" code before execution. This leads to significant performance acceleration, which typically reduces the overall server's memory consumption and has few drawbacks.

2. Comparison of advantages and disadvantages between optimizer+ and APC?

Optimizer+ was renamed Opcache in mid-March 2013.

Based on the discussion on the PHP wiki, Zend Opcache is about to be integrated into PHP 5.5. As an APC competitor, the new Zend Opcache is likely to replace the APC location, although Optimizerplus does not have the user cache function like APC.

optimizer+ Advantages Relative to APC?

1. Performance. According to the test, Zend optimizer+ is always superior to APC. With code differences, the number of requests processed per second is 5~20% high. Google Doc recorded on the test results, WordPress 2.1.1 (do not know why not a new version of WP to test), performance improvement of about 8%. Theoretically, for WP 3.5.1, performance should also be able to get about 5~10% upgrade it. For servers running WordPress, using optimizer+ can significantly reduce CPU usage and increase page load speed (graphics here).
2. Support for new PHP versions. Zend and the PHP community will help optimizer+ to support the latest version of PHP.
3. Reliability. The optimizer+ has an optional corruption detection capability to prevent server crashes due to data corruption.
4. Better compatibility. The PHP community intends to make optimizer+ compatible with all PHP versions supported by the community.

Advantages of APC Relative optimizer+?

1. APC has a data caching API, and optimizer+ does not.
2. APC is able to reclaim memory consumed by old invalid scripts. APC has a memory manager that can reclaim memory associated with scripts that are no longer in use. Unlike optimizer+, it marks such memory as "dirty", but does not reclaim them. Once the percentage of "dirty" memory footprint configuration thresholds reaches a certain value, optimizer+ will restart itself. This behavior has both advantages and disadvantages in stability.

3. Using Zend Opcode?

It is now possible to use Zend Opcache instead of APC as the PHP Optimizer acceleration tool. The current Zend Opcode is compatible with PHP 5.2.*, 5.3.*, 5.4.*, and PHP-5.5 development editions. However, support for PHP 5.2 will be canceled in the future.

Note : Zend opcache conflicts with Eaccelerator. To install Zend Opcache, you may need to uninstall eaccelerator--first if you use this accelerator module.

Install and configure from source?

Zend Opcache's source code is hosted on GitHub and is currently called Zendoptimizerplus.

The installation steps are described in the README file.

Attention:

1. It is best to test in the local virtual machine before deploying to your own server;
2. It is best to remove components such as Eacceleratro, XCache, or APC before installing.

By the way, Php-devel is required to compile the installation from the source code. The beginning of the Quick Install section of the README is used,

$PHP _dir/bin/phpize

If you don't know the path to the Phpize,

Whereis phpize

The README file also has the corresponding recommended optimization settings.

Installing and configuring from a EPEL source?

I do not like to compile the installer from the source code, one is the level is limited, one is afraid of trouble. The following is an example of installing Zend Opcache from the EPEL installation source to the CentOS operation, based on my VPS configuration.

The EPEL community has provided a Zend Opcache installation package that can be installed directly with Yum. Of course, the premise is that you have configured an installation source that uses EPEL. If not, you can refer to this.

As a reminder, PHP on the REMI installation source is already in version 5.4. Given the test that WordPress has better performance on PHP 5.4 than on PHP 5.3 (10% faster and lower ram consuming), it's not a bad thing to upgrade PHP by the way.

Operation Steps:

2. The configuration uses the Epel installation source. Skipped if there are already.
4. Remove Eaccelerator, XCache, APC:

   Yum Remove Php-eaccelerator Php-xcache PHP-APCU

   Skipped if not used.

5. To perform an upgrade on the system:

   Yum Update

   The purpose is to upgrade the current PHP software to the latest version supported by Remi based on the status of the Remi installation source. At this point, you can see that the system has output similar to the following:

   Updating   : php-common-5.4.14-1.el6.remi.i686                                                         1/26warning:these php-* RPM is not official fedora/red Hat build Andoverrides the official ones. Don ' t file bugs on Fedora Project nor Red hat.use dedicated forums http://forums.famillecollet.com/warning:/etc/php.ini C reated as/etc/php.ini.rpmnew  Updating   : mysql-libs-5.5.31-1.el6.remi.i686                                                         2/26warning:this MySQL RPM is Not a official fedora/red Hat build and itoverrides the official one. Don ' t file bugs on Fedora Project nor Red hat.use dedicated forums http://forums.famillecollet.com/warning:/ETC/MY.CNF cr Eated as/etc/my.cnf.rpmnew

   It means we're migrating from fedora/red hat to the Remi version, so don't go to fedora/red hat for help. Hehe, seemingly problems are found on the internet, and really rarely to the official forum to ask questions. Entry-level users like me do not experience that depth of problem.

7. Install Zend Opcache (pecl version):

   Yum Install Php-pecl-zendopcache

   The configuration file for the Opcache generated at the time of installation is located in the default/ETC/PHP.D directory:

   Opcache-default.blacklistopcache.ini

   This configuration file is basically the recommended setting in the README, only a few places need to be modified.

   Vi/etc/php.d/opcache.ini

   Modify and save the following recommended configurations (refer to the full Zend Opcache configuration information):

   opcache.memory_consumption=128opcache.interned_strings_buffer=8opcache.max_accelerated_files= 4000opcache.revalidate_freq=60opcache.fast_shutdown=1opcache.enable_cli=1

9. You do not need to modify the php.ini configuration to restart the Apache service for it to take effect:

   Service httpd Restart

Check to see if it started correctly:

Php-v

The output is similar to the following:

PHP 5.4.14 (CLI) (built:apr 11:04:35) Copyright (c) 1997-2013 the PHP groupzend Engine v2.4.0, Copyright (c) 1998- Zend Technologies with    Zend opcache v7.0.1, Copyright (c) 1999-2013, by Zend Technologies

4. Experience?

PHP has a lot of opcode cache components, such as APC, Eaccelerator, XCache and so on. (See the PHP accelerators list on Wikipedia.) Look at the meaning of the PHP wiki, the new Zend Opcache performance should be the best. No matter which component you use, it will always be a good one.

For small servers, it seems that the performance differences of these components are not too obvious. My idea is that since it's used, use the best one. But if you're using a different opcode cache, such as one of the ones mentioned above, there's no need to change it right away from performance improvements.

For this station, homepage generation time: PHP only, about 0.9s, use eaccelerator about 0.63s, after using Zend opcache about 0.55s. The test was very rudimentary, open a few times to see how WP Super Cache provides page generation time, estimated an average.

Log in to the system and look at the memory footprint of the Apache process. Before a process can occupy more than 40MB of memory, and now basically no more than 40MB. Just don't know is PHP 5.4 credit, or Zend Opcache credit.

I wonder what you think of the effect of this Zend Opcache? If you are interested, you may wish to leave a message to write down your test results. ?

Accelerating PHP with Zend Opcache (2)