PHP Performance Analysis and Experiment-macro performance analysis (1)

PHP Performance Analysis and Experiment-macro performance analysis (1)

Editor's note]I have read a lot of articles on PHP performance analysis before, but I have written a single rule, and these rules have no context, there is no clear experiment to reflect the advantages of these rules, and the discussion also focuses on some grammar points. This article will change the perspective of PHP performance analysis, and analyze the points of attention and improvement in PHP performance through examples.

For the analysis of PHP performance, we started from two levels and divided this article into two parts: one is the macro level, and the so-called macro level is the PHP language itself and the Environment level, one is the application layer, that is, the syntax and rules used. However, it not only explores the rules, but also assists in sample analysis.

At the macro level, the performance analysis of the PHP language itself is divided into three aspects:

I. Performance Analysis and Improvement of PHP as an explanatory language

PHP, as a scripting language, is also an explanatory language, and is the reason for its natural performance limitations, because it is different from compiling a language into binary code before it runs, each run of an explanatory language is subject to the input, parsing, compilation, and execution of the original script. The following is the execution process of PHP as an explanatory language.

As shown above, we can see that each running process has three processes: parsing, compiling, and running.

Where are the optimization points? As long as the code file is determined, the parsing to compilation step is all determined, because the file is no longer changed, while the execution is different because the input parameters are different. In the world of performance optimization, the best trick is to reduce operations with the same results. This is the well-known cache. Cache is everywhere, and cache is the best tool for performance optimization. As a result, the OpCode cache action appeared, only the first time needed to be parsed and compiled, and in subsequent execution, the script was directly directed to the Opcode, thus speeding up the performance. The execution process is shown in:

The efficiency of reading bytecode directly from the cache after each parsing, compilation, and script is greatly improved. How much is the improvement?

Let's do an experiment without Opcode caching. 20 concurrent requests that have not passed the opcode cache for a total of 10000 requests, the following results are obtained:

Next, we open the Opcode cache on the server. To implement opcode caching, you only need to install APC, Zend OPCache, and eAccelerator extensions. Only one of them is enabled even if multiple packages are installed. Note that after modifying the php. ini configuration, you need to re-load the php-fpm configuration.

Here we enable APC and Zend OPCache respectively for experiments. Enable the APC version.

We can see that the speed has been greatly improved. Originally, each request was 110 ms, 182 requests were processed per second, 68 ms after APC was enabled, and 294 requests were processed per second, the increase speed is nearly 40%.

In the version with Zend Opcache enabled, the results are roughly the same as those of APC. Processing 291 requests per second takes 68.5 ms.

From the above experiment, we can see that the test page used spends more than 40 ms on Syntax Parsing and compilation. By caching these two operations, the processing speed can be greatly improved.

Here, I will add some additional information about what OpCode is. We can use bytekit or the vld PHP extension to compile PHP code. The following is the running result of the vld plug-in parsing code.

You can see that each line of code is compiled into the corresponding OpCode output.