PHP performance analysis and experiment: macro performance analysis

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.

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:

1. PHP's performance as an explanatory language has its natural defects.
2. As a dynamic language, PHP also has room for improvement in performance.
3. Current mainstream PHP version language engine performance

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.

II. performance analysis and improvement of PHP as a dynamic language

The second is that the PHP language is a dynamic language. the dynamic language itself involves the type inference in the memory. for example, in PHP, we can get an integer by adding two integers, an integer is added to a string, and even two strings are added to an integer. The string and any type of connection operation are strings.

 
The running result is as follows:
float(40.11) int(40) int(30) int(30)
The dynamic types of languages provide convenience for developers, and the language itself reduces efficiency due to the dynamic types. In Swift, there is a feature called type inference. we can see how much efficiency difference type inference will bring? For Swift code that requires type inference and does not require type inference, let's compile it to see how it works. The first code is as follows:
This is a piece of Swift code. the dictionary has only 14 key-value pairs. the compilation of this code has not been completed in 9 minutes (5 GB memory, 2.4 GHz CPU ), the compiling environment is Swift 1.2 and Xcode 6.4.
However, if the code is adjusted as follows:
That is, the type restriction is added to avoid the type inference of planeLocation. The compilation process took 2 S.
It can be seen that the type inference operation attached as a dynamic type greatly reduces the compilation speed of the program. Of course, this example is a bit extreme. it is not appropriate to use Swift to compare PHP, because the Swift language is still evolving. This example only shows that in a programming language, if it is a dynamic language, it involves processing dynamic types, which will be affected from the compilation perspective.
How can we improve the efficiency of dynamic PHP? There is no way to solve this problem from the PHP language itself, because it is also a dynamic type of code. The solution is to convert PHP to a static representation, that is, to make an extension. we can see that many of the projects of laruence, such as the Yaf framework, are made extension, of course, this is also because laruence is a master of C. Because the extension is written in C or C ++, it is no longer a dynamic type and compiled, and the efficiency of the C language itself will be improved a lot. Therefore, the efficiency will be greatly improved.
Next let's look at a piece of code. this code only implements a simple Prime number Operation. it can calculate the number of prime numbers within a specified value, using a common embedding method. Now let's look at the differences between the extension implementation and the native PHP implementation efficiency. of course, this difference is not only the difference between the dynamic type and the compilation type, but also the difference in language efficiency.
First, the algorithm written in PHP is used to calculate the number of prime numbers less than 10 million, which takes up to 33 s. after three experiments, the results are basically the same.
Secondly, we compile the process of calculating the number of prime numbers into PHP Extensions. in the extension, we implement the getprimenumbers function, input an integer, and return a prime number smaller than this integer. The result is as follows. the efficiency improvement is amazing. it is returned within 1.4 s. The speed is increased by more than 20 times.
As you can imagine, the efficiency of static and compiled languages has been dramatically improved. The C language code of this program is as follows:
PHP_FUNCTION(get_prime_numbers){ long value; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "l", &value) == FAILURE) { return;    } int *numbers = (int *)malloc(sizeof(int)*128*10000); memset(numbers, 0x0, 128*10000); int num = 2;        numbers[0] = 2;        numbers[1] = 3; bool flag = true; double f = 0; int i = 0; int j = 0; for(i=5; i<=value; i+=2)        {            flag = true;            f = sqrt(i); for(j=0; j
  
   f)                { break;                }            } if(flag)            {                 numbers[num] = i;                num++;            }        } free(numbers);        RETURN_LONG(num);}
  
III. Improvement of the underlying performance engine of the PHP language
The third level of performance optimization is the performance improvement of the language itself. this is not what we can do for common developers. Before PHP 7, I hoped to improve the minor version, but the improvement was not very significant, for example, PHP 5.3, PHP 5.4, PHP 5.5 compared the performance of the same piece of code and made some progress.
The PHP 5.3 version has been mentioned in the above example. It takes about 33 s. now let's look at other PHP versions. Run the following commands respectively:
PHP version 5.4 has been improved to some extent compared with version 5.3. About 6 seconds.
The PHP 5.5 version has taken another step on the basis of PHP 5.4, which is 6 S faster.
PHP5.6 regresses.
PHP 7 is an amazing improvement in efficiency, more than three times that of PHP5.3.
The above is the difference in the running speed of the prime script in various PHP versions. although only this program is tested, it is not particularly rigorous, but it is on the same machine, in addition, the configure parameter compilation is basically the same, and there is a certain degree of comparability.
On the macro level, in addition to the above, in the actual deployment process, the optimization of PHP performance also reflects the need to reduce the resources consumed during the operation. Therefore, FastCGI mode and mod_php mode are more popular than traditional CGI mode. In the traditional CGI mode, all modules need to be loaded during each script operation. After the program runs, the module resources must be released. As shown in:
This is not required in FastCGI and mod_php modes. Only when php-fpm or Apache is started, all modules need to be loaded once. in a specific running process, related module resources do not need to be loaded and released again.
In this way, the program performance is improved. The above is an analysis of PHP performance optimization at the macro level. in the second part of this article, we will discuss the PHP optimization principles for application. Coming soon!