In-depth discussion on PHP Performance

1. Origin

With regard to PHP, many people intuitively feel that PHP is a flexible scripting language with rich library classes, simple to use, and secure. It is very suitable for WEB development, but its performance is low. Is PHP performance really as bad as everyone feels? This article focuses on this topic. This article analyzes PHP performance problems in terms of source code, application scenarios, benchmark performance, and comparative analysis, and uses real data to speak.

2. Analysis of PHP performance based on principles

The Principle Analysis of PHP performance mainly involves the following aspects: memory management, variables, functions, and operating mechanisms.

2.1 Memory Management

Similar to Nginx memory management, PHP is also based on the memory pool internally and introduces the concept of the lifecycle of the memory pool. In terms of the memory pool, PHP manages PHP scripts and all extended memory-related operations. The management of large and small memory uses different implementation methods and optimizations. For details, refer to the following documents: https://wiki.php.net/internals/zend_mm. During the lifecycle of memory allocation and recovery, PHP uses an initialization application + dynamic expansion + Memory ID collection mechanism, and directly re-creates a mask for the memory pool after each request.

2.2 Variables

PHP is a language of the weak variable type. Therefore, in PHP, all PHP variables correspond to a type of Zval, which is defined as follows:

Figure 1 PHP Variables

In terms of variables, PHP has done a lot of optimization work, such as the Reference counting and copy on writer mechanisms. This ensures optimized memory usage and reduces the number of memory copies (see http://blog.xiuwz.com/2011/11/09/php-using-internal-zval /). In terms of arrays, PHP uses efficient hashtable internally.

2.3 Functions

In PHP, all PHP functions are converted into an internal function pointer. For example, extended functions

1. ZEND_FUNCTION (my_function); // similar to function my_function (){}

After being expanded internally, it will be a function.

1. void zif_my_function ( INTERNAL_FUNCTION_PARAMETERS );  

2. Void zif_my_function (
3. Int ht,
4. Zval * return_value,
5. Zval * this_ptr,
6. Int return_value_used,
7. Zend_executor_globals * executor_globals
8. );
9.  

From this perspective, the PHP function also corresponds to a function pointer internally.

2.4 Operating Mechanism

When talking about PHP performance, many people will say that "C/C ++ is a compilation type, JAVA is a semi-compilation type, and PHP is an interpreted type ". That is to say, PHP performs dynamic parsing before code execution. From this perspective, PHP performance must be poor.

Indeed, the output from the PHP script is indeed a process of dynamic parsing and code execution. Specifically, the PHP script running mechanism is shown in:

Figure 2 PHP Running Mechanism

PHP is also divided into three stages:

• Parse. Syntax analysis stage.
• Compile. Compile and generate the opcode intermediate code.
• Execute. Running, dynamic running for output.

Therefore, there is a compilation process in PHP itself. A large number of opcode cache tools, such as apc, eacc, and xcache, are generated accordingly. These opcode caches are standard in the production environment. Based on opcode cache, you can achieve the "one-time PHP script compilation and multiple operations" effect. From this point on, PHP and JAVA semi-compilation mechanisms are very similar.

Therefore, from the perspective of the operating mechanism, the PHP running mode is very similar to that of JAVA, which generates intermediate Codes first and then runs on different virtual machines.

2.5 Dynamic Operation

From the above analysis, PHP has done a lot of work in terms of memory management, variables, functions, and operating mechanisms. Therefore, from the perspective of principle, PHP should not have performance problems, the performance should at least be close to that of Java.

At this time, we have to talk about the performance problems caused by the characteristics of PHP Dynamic Language. Because PHP is a dynamic runtime, therefore, all variables, functions, object calls, and scope implementations are identified in the execution phase. This fundamentally determines some things that are difficult to change in PHP performance: variables and functions that can be determined at the static compilation stage, such as C/C ++, in PHP, it is determined that the PHP intermediate code cannot be directly run and must be run on the Zend Engine.

Speaking of the specific implementation of PHP variables, I have to say another thing: Hashtable. Hashtable can be said to be one of the soul of PHP. It is widely used in PHP, including variable symbol stack and function symbol stack. It is based on hashtable.

Take the PHP variable as an example to illustrate the dynamic running characteristics of PHP, such as the Code:

1. <?php 

2. $ Var = "hello, blog.xiuwz.com ";
3. ?>
4.  

The execution result of this Code is to add an item in the variable symbol stack (A hashtable ).

When the variable is used, it is searched in the stack according to the variable (that is, the process of a hash query for the variable call ).

Similarly, for function calls, there is basically a function symbol stack (hashtable ).

In fact, the characteristics of dynamic variable search can also be seen in the PHP operating mechanism. PHP Code is interpreted and compiled in the following process:

Figure 3 PHP running instance

As you can see, PHP code after compile produces the Class symbol table, function symbol table, and OPCODE. During actual execution, zend Engine searches and processes the corresponding symbol table based on the op code.

To some extent, it is difficult to find a solution to this problem. This is determined by the dynamic characteristics of the PHP language. However, many domestic and foreign users are looking for solutions. In this way, PHP can be completely optimized. A typical column is facebook's hiphop (https://github.com/facebook/hiphop-php ).

2.6 conclusion

According to the above analysis, there is no obvious performance difference in the basic memory management, variables, functions, and running mechanisms of PHP, but due to the dynamic running characteristics of PHP, it determines the CPU overhead and extra memory overhead of all variable search and function running in PHP compared with other compiled languages, it can be obtained through subsequent benchmark performance and comparative analysis.

Therefore, it can be seen that PHP is not suitable for some scenarios: a large number of computing tasks, operations on large data volumes, and applications with strict memory requirements. If you want to implement these functions, you are also recommended to implement them through extension, and then provide the hook function for PHP to call. This reduces the overhead of variable and Function Series in internal computing.

3. benchmark performance

Standard Data is missing for PHP benchmark performance. Most people have a perceptual knowledge. Some people think that QPS is the limit of PHP. In addition, there is no authoritative number to respond to the performance of the framework and the impact of the framework on the performance.

The purpose of this section is to provide a benchmark reference performance indicator and give you an intuitive understanding of the data.

The specific benchmark performance includes the following aspects:

1. Bare PHP performance. Complete basic functions.

2. Performance of the bare framework. Only the simplest route distribution is required and core functions are used.

3. benchmark performance of the standard module. The benchmark performance of a standard module refers to the benchmark performance with complete service module functions.

3.1 Environment Description

Test environment:

 

Uname-

Linux db-forum-test17.db01.baidu.com 2.6.9 _ 5-7-0-0 #1 SMP Wed Aug 12 17:35:51 CST 2009 x86_64 x86_64 x86_64 GNU/Linux

Red Hat Enterprise Linux AS release 4 (Nahant Update 3)

8 Intel (R) Xeon (R) CPU E5520 @ 2.27 GHz

Software related:

 

Nginx:

Nginx version: nginx/0.8.54 built by gcc 3.4.5 20051201 (Red Hat 3.4.5-2)

Php5: (using php-fpm)

PHP 5.2.8 (cli) (built: Mar 6 2011 17:16:18)

Copyright (c) 1997-2008 The PHP Group

Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

With eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator

Bingo2:

PHP framework.

Other Instructions:

Deployment method of the target machine: script.

The stress testing machine and the target machine are deployed independently.

3.2 bare PHP Performance

The simplest PHP script.

1. <?php 

2. Require_once './actions/indexAction. php ';
3. $ ObjAction = new indexAction ();
4. $ ObjAction-> init ();
5. $ ObjAction-> execute ();
6. ?>
7. The code in Acitons/indexAction. php is as follows:
8. <? Php
9. Class indexAction
10. {
11. Public function execute ()
12. {
13. Echo 'hello, world! ';
14. }
15. }
16. ?>
17.  

The test results by using the stress tool are as follows:

3.3 bare PHP framework performance

To compare with 3.2, similar functions are implemented based on the bingo2 framework. The Code is as follows:

1. <?php 

2. Require_once 'bingo/Controller/Front. php ';
3. $ ObjFrontController = Bingo_Controller_Front: getInstance (array (
4. 'Actiondir' => './actions ',
5. ));
6. $ ObjFrontController-> dispatch ();

The stress test results are as follows:

From the test results, we can see that although the framework has a certain amount of consumption, the impact on the overall performance is very small.

3.4 benchmark performance of the standard PHP Module

The so-called standard PHP module refers to the basic functions required by a PHP module:

Route distribution.

Auto load.

LOG initialization & Notice LOG printing. Therefore, all the UI requests have a standard log.

• Handle errors.
• Time correction.
• Automatically calculates the time consumption of each stage.
• Encoding recognition & encoding conversion.
• Parsing and calling of standard configuration files

Use the bingo2 code automatic generation tool to generate the standard test PHP module: test.

The test results are as follows:

3.5 conclusion

From the conclusion of the test data, the PHP performance is still acceptable. The benchmark performance can reach thousands or even hundreds of thousands of QPS. As to why the performance in most PHP modules is poor, we should find out the bottleneck of the system at this time, but simply say OK, PHP doesn't work, so let's change to C. (In the next chapter, we will use some examples to compare and use C to deal with it without special advantages)

The following conclusions can be drawn from the benchmark data:

1. PHP has good performance. With simple functions, QPS can be reached, and the limit can be over W.

2. the PHP framework has very limited impact on performance. Especially when there is a certain amount of business logic and data interaction, it can be ignored.

3. A standard PHP module with a benchmark performance of up to QPS (80 cpu idle ).

4. Comparative Analysis

Most of the time, when you find that the PHP module has poor performance, you can say "OK, let's rewrite it with C ". In the company, the use of C/C ++ to write business logic modules is everywhere. In the past few years, almost all of them were written using C. At that time, what we wrote was really painful: difficult debugging and agile.

Article by: baidu-tech.com