Performance analysis and experiment of PHP--a macroscopic analysis of performance

"Editor's note" before, read a lot about PHP performance analysis of the article, but the writing is a rule, and these rules do not have context, there is no clear experiment to reflect the advantages of these rules, while the discussion also focused on some grammatical points. This article changes the angle of PHP performance analysis, and through the example to analyze the performance aspects of PHP need to pay attention to and improve the point.

PHP performance Analysis, we start from two levels, the article is also divided into two parts, one is the macro level, the so-called macro-level, is the PHP language itself and the environment level, one is the application level, is the grammar and the use of rules, but not only to explore the rules, but also to help show examples of analysis.

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

1. PHP as an explanatory language performance has its natural flaws
2. PHP as a dynamic type language also has a space to improve performance
3. The current mainstream PHP version itself language engine performance

I. Performance analysis and promotion of PHP as an explanatory language

PHP, as a scripting language and an explanatory language, is the reason why its natural performance is limited because, unlike a compiled language, compiled into binary code before it runs, the explanatory language runs on each run with the input, parsing, compiling, and execution of the original script. The following is the implementation of PHP as an explanatory language.

As shown above, as you can see, every run requires three parsing, compiling, and running three processes.

Where is the optimized point? It is conceivable that, as long as the code file is determined, parsing to compile is determined, because the file is no longer changing and execution is different because of the input parameters. In the world of performance optimization, the first trick is to get the same results in the case of reduced operations, which is the famous cache. Caches are everywhere, and caching is the killer of performance optimizations. Thus OpCode cache This trick appears, only the first need to parse and compile, and in the subsequent execution, directly from the script to OpCode, so as to achieve the performance speed. The execution process is as follows:

Relative to each parse, compile, read to the script, directly from the cache to read the efficiency of the bytecode will be greatly improved, the extent of the increase in the end how much?

Let's do an experiment with no Opcode cache. 20 concurrent, a total of 10,000 requests without a opcode cache request, get the following result:

Second, we open the Opcode cache on the server. To implement the opcode cache, you only need to install the APC, Zend Opcache, eaccelerator extensions, and only one is enabled, even if multiple installations are installed. Note that the configuration of the PHP-FPM needs to be reloaded after the php.ini configuration has been modified.

Here the APC and Zend Opcache are respectively enabled for experimentation. Enable the version of APC.

Can be seen, the speed has a larger increase in the original 110ms per request, processing requests per second 182, enabled APC after 68ms, processing requests per second 294, lifting speed of nearly 40%.

In the version with Zend Opcache enabled, the results are roughly equivalent to that of APC. Processing requests per second of 291, each request time consuming 68.5ms.

From the above experiment can be seen, the test page used, more than 40ms of time spent on the syntax parsing and compiling the two. By caching These two operations, you can significantly increase the speed of this process.

Add up here, OpCode what exactly is the east, OpCode compiled bytecode, we can use bytekit such tools, or use the VLD PHP extension to implement code compilation for PHP. The following is the result of running the VLD plugin parsing code.

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

Second, the performance analysis and improvement of PHP as a dynamic type language

The second is that the PHP language is a dynamic type of language, the dynamic type of the language itself because it involves in-memory type inference, such as in PHP, two integers, we can get integer values, an integer and a string to add, even two strings added, all become integers added. Strings and any type of join operations are strings.

<?php$a = 10.11;$b = "30";var_dump($a+$b);var_dump("10"+$b);var_dump(10+"20");var_dump("10"+"20");

The results of the operation are as follows:

float(40.11)int(40)int(30)int(30)

The dynamic type of language is convenient for developers, and the language itself is less efficient because of the dynamic type. In Swift, there is a feature called type inference, and we can see how much of an efficiency difference the type inference brings. For two pieces of Swift code that require type inference and no need for type inference, we try to compile to see how it works.
The first piece of code is as follows:

This is a swift code, the dictionary has only 14 key-value pairs, this code compiles, 9 minutes has not been compiled (5G memory, 2.4GHz CPU), the compilation environment for Swift 1.2,xcode 6.4.

But if the adjustment code is as follows:

That is, the type qualification is added to avoid the planelocation type inference. The compilation process took 2S.

As you can see, the type inference operation that is attached as a dynamic type greatly reduces the compilation speed of the program.
Of course, this example is a bit extreme, and it's not necessarily appropriate to use Swift to analogy PHP, because the swift language itself is still evolving. This example simply indicates that in a programming language, if it is a dynamic type language, the processing of dynamic types is involved, which is affected from the point of compilation.

What about the efficiency of PHP as a dynamic type? There is no way to solve this aspect of the PHP language itself, because you can write code that is also dynamic type. The solution is to convert PHP into a static type of representation, that is, to make an extension, you can see that many of the bird brother's projects, such as the YAF framework, are made to expand, of course, this is also because the bird brother is a C master. Extensions are written in C or C + +, so they are no longer dynamic types, plus they are compiled, and the efficiency of the C language itself increases a lot. So the efficiency will be greatly improved.

Let's take a look at a piece of code, this code, just implements a simple prime operation, can calculate the number of elements within a specified value, using a common filtering method. Now look at the extension implementation, the efficiency difference with PHP native implementation, the difference of course, not just the difference between the dynamic type and the compilation type, but also the difference in language efficiency.

The first is the use of pure PHP algorithm, the calculation of the number of elements within 10 million, time-consuming at 33s up and down, the experiment three times, the results are basically the same.

Secondly, we have compiled this process of number of primes into PHP extensions, implemented the Get_prime_numbers function in the extension, entered an integer, and returned the primes less than that integer. The results are as follows, and this increase in efficiency is very alarming and is returned at 1.4s. 20 times times more speed.

As you can imagine, the efficiency of static and compile-type 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<num;j++)            {                if(i%numbers[j]==0)                {                    flag = false;                    break;                }                if(numbers[j]>f)                {                    break;                }            }            if(flag)            {                 numbers[num] = i;                num++;            }        }        free(numbers);        RETURN_LONG(num);}

Third, the PHP language itself the underlying performance engine upgrade

The third aspect of performance optimization is the performance improvement of the language itself, which is not something that our ordinary developers can do. Before PHP 7, the hope is that the minor version of the improvement, but the improvement is not very significant, such as PHP 5.3, PHP 5.4, PHP 5.5, PHP 5.5 for the same piece of code performance comparison, there is a certain degree of progress.

The version of PHP 5.3 has been described in the above example, it takes about 33s of time, we now look at other versions of PHP. Run the following separately:

PHP version 5.4, compared to the 5.3 version has been a certain degree of improvement. About 6 seconds.

PHP version 5.5 in PHP 5.4 on the basis of another step, faster 6S.

PHP5.6 a little bit backwards instead.

PHP 7 is really an amazing efficiency boost, is more than 3 times times the PHP5.3.

The above is the number of versions of the script in each PHP version of the speed difference, although only testing this program, is not particularly rigorous, but this is on the same machine, and the compiler configure parameters are basically the same, or there is a certain comparability.

At the macro level, in addition to these above, in the actual deployment process, the performance of PHP optimization, but also to reduce the resources consumed in the run. So FastCGI mode and mod_php mode are more popular than traditional CGI models. Because in the traditional CGI mode, all the modules need to be loaded at every time the script is run. The module resource is also freed after the program has finished running. As shown in the following:

In the FastCGI and mod_php modes, this is not required. Only when the PHP-FPM or Apache boot, you need to load all the modules, in a specific run process, do not need to load and release the relevant module resources.

This improves the efficiency of the program's performance. The above is about the PHP macro-level performance optimization analysis, in the second part of this article we will explore the application of the PHP optimization guidelines. Please look forward to!

This article is compiled and collated by OneAPM engineers. OneAPM is an emerging leader in application performance management, enabling enterprise users and developers to easily implement slow program code and real-time crawling of SQL statements. To read more technical articles, please visit the OneAPM official blog.

Performance analysis and experiment of PHP--a macroscopic analysis of performance