PHP Performance Evolution (full evaluation of performance from PHP5.0 to PHP7.1)

This article is originally from abroad this article: PHP performance Evolution 2016, thanks to the high-availability architecture of the public number translated into the Chinese version, here is reproduced in the highly available architecture translated articles from PHP 5 to PHP 7 performance full evaluation (including the unpublished JIT version of PHP 8 contrast), A slightly adjusted format.

Introduction: PHP is the most commonly used language in WEB development, and each large version of the update brings many new features and performance improvements. In particular, the release of PHP 7.0 brings a leap in PHP performance. The author of this article performs a benchmark of CPU performance for each PHP version and brings the next large version of PHP to the message. The Chinese version of this article is translated by a highly available architecture volunteer.

Since 1994 Rasmus Lerdorf created PHP, the PHP language has undergone many improvements, with performance being one of the key criteria that developers consider when evaluating a new version.

Read this article to learn about the performance gains from PHP 5 to 7 (including 7.1), as well as the performance of the experimental JIT branch version that is about to be added to PHP 8.

Brief introduction

This article will update on time to add more information and benchmark results, including new releases that have not yet been released, to better understand the evolution of PHP performance over the years. If you have corrections or suggestions for improvement, please leave a message after the article.

Since 1994 Rasmus Lerdorf created PHP, the PHP language has undergone a fierce evolution. Although the first edition was a simple one-man-developed CGI program, Rasmus Lerdorf, Andi Gutmans and Zeev Suraski joined the development of the third version of the language and fundamentally redesigned it. Since then, the PHP Development Group has also been created and developed.

With the development of the project, due to PHP 3 's natural extensibility, PHP's capabilities in core and extension development have been booming, such as network communication, parsing, caching and database support.

The language itself is also evolving, bringing a series of improvements. This includes support for object-oriented structures such as classes, interfaces, traits, closures, and so on.

For many developers, only new features are not enough. As languages become more and more popular, the PHP community is increasingly demanding to provide better performance, scalability, and less memory usage.

The PHP development team has been working on these requirements for nearly 20 years, although the introduction of PHP 3 has greatly improved performance, but until Andi Gutmans and Zeev Suraski introduced Zend Engine and published PHP 4, PHP's performance began to become formal.

The new memory compiler and actuator model introduced in 2000 greatly improved PHP performance (5 times or even 10 times times) and was first used by formal WEB applications and sites. We can say that the results of PHP today are far beyond anyone's expectations when the PHP project was born.

The boom in PHP has added to the desire to improve performance. Fortunately, the model designed in Zend Engine provides a good basis for continuous optimization of performance.

While PHP 5.0 does not deliver substantial performance gains, and in some cases is even slower than PHP4, a team led by Dmitry Stogov has been continuously refining the language in subsequent releases with the help of the community, and in most cases, in the case of PHP 5.6, performance has increased by 1 . between 5x and 3x.

In December 2015, PHP 7.0 made a major breakthrough. The 7.1 release also brought a series of enhancements in December 2016.

PHP 8 Performance Outlook

This is a promising version, currently under development, led by Zend's Dmitry stogov. Although it is based on the PHP 7.1 version, but the actual version number has not yet been defined, so this article says this version is under the "Experiment JIT" branch.

Critical function JIT (just-in-time) compilation is a technique for translating code into another bytecode, such as the local code that runs its machine CPU. JIT can make programs run faster.

This article covers the results of several benchmarks, from the first version of PHP 5 to the Experimental JIT branch version of PHP, and the version performance prior to PHP 5 is not covered in this article.

In writing this article, it is difficult to determine if PHP 8 will have another major version, such as PHP 7.2. But it can be assumed that when PHP 8 was released, it already included the power of the current trial version of the JIT branch.

PHP Performance evaluation

This article only runs baseline tests for pure CPU task scripts (tasks that do not require I/O operations such as access to files, network, or database connections).

The baseline test script used is as follows:

1. Bench.php can be used in the Php-src/zend directory of PHP source code
2. Micro_bench.php can also be found in the PHP source code published in the Php-src/zend directory
3. mandelbrot.php https://gist.githubusercontent.com/dstogov/12323ad13d3240aee8f1/raw/ 37fed3beb7e666b70e199bcf361af541b3c30d2d/b.php

Benchmark scripts run only with the latest iteration of each PHP major version. Therefore, the version of the test is as follows:

1. 5.0.5
2. 5.1.6
3. 5.2.17
4. 5.3.29
5. 5.4.45
6. 5.5.38
7. 5.6.28
8. 7.0.13
9. 7.1.0
10. Php-jit (JIT Experiment Branch)

Of course, I want to make sure that we run all the minor versions on the same benchmark, for example, between 5.3.0 to 5.3.29. The result is convincing: the main performance enhancements are not the minor versions, but the major version numbers, such as PHP 5.4 to PHP 5.5, or PHP 5.6 to PHP 7.

The minor version does not show any noticeable performance improvements. This means that the same script should run at the same speed, whether you use PHP 5.4.0 or PHP 5.4.45.

You can view the baseline process section, detailing the settings of the host system, how each benchmark operates, and how the timing results are interpreted.

Pure CPU Benchmark test results

This section gives the benchmark test results for each PHP version.

Each datum column displays a value of 3:

• Time: Execution time, in seconds and milliseconds
• %rel, Gain: The execution time relative to the previous version of the gain. In the table below, for example,%rel. The benefit of bench.php and version 5.3.29 is 31.89%, meaning that the script runs 31.89% faster than the 5.2.17 version.
• %abs, Gain: The benefit of script running compared to PHP 5.0. If you look at the intersection of this column of bench.php and the experimental JIT branch, you'll notice that PHP 8 is 41 times times faster than PHP 5.0 for this particular test benchmark.

The results of the pure CPU benchmark are as follows:

CPU Benchmark Test

(1) The test cannot be run on a version prior to 5.3 because it uses an object feature that has not yet been implemented.
(2) The result in this column is a bit biased, because the benchmark requires at least PHP 5.3 to run. Think of them as purely illustrative, as they cannot be compared to PHP 5.0 performance.
(3) This is a modified version of the mandelbrot.php script, it runs too fast, in 7.1.0 and the trial JIT branch does not have accurate statistical time, we run the calculation 100 times in the script instead of 1 times.

Of course, these are all purely CPU benchmarks. They do not cover all aspects of PHP performance, and they may not represent the real situation. But the results are significant enough to illustrate several aspects of the problem:

• PHP 5.1 improves performance by more than PHP 5.0
• 5.2 and 5.3 brought some of their own performance enhancements, but they were not as compelling as the 5.1 version.
• Version 5.4 is a big performance improvement. (Here are some of the PHP5.4 performance-optimized speeches I've shared PPTPHP-5.4 performance)
• The Opcache extension is bundled with versions 5.5 and 5.6. When the same script runs continuously on the WEB server, there is a performance boost due to faster code loading. However, Opcache does not really show the benefits of executing scripts in CLI mode.
• PHP 7.0 is a major breakthrough in performance. Zend Engine has been completely redesigned and we can see the results of this work here. (Here are the PPT of PHP7 's performance optimized speech I've shared, the secret of php7′s performance)
• PHP 7.1 introduced the opcode optimization in the opcache extension. This again explains the performance gain in the table above when compared to 7.0. (Here are some of the PHP7.1 performance optimizations I've shared pptphp 7.1′s New Features and performance
• Experimenting with the JIT branch is another major breakthrough, and the JIT can provide great performance improvements to existing code, but in some cases you may notice that the speed increase is only a few percent, and in the worst case, it may even slow down because the compilation does not generate faster code. Keep in mind that this feature is currently under development.

This section describes the results of the 3 pure CPU benchmark scripts. It doesn't give the same number when running a PHP application that typically performs a database or file access to a typical scenario, but I think they can represent a performance improvement that you expect for some part of the code.

Performance improvements per version of PHP

PHP 5 provides significant improvements over PHP 4. Zend engine is the core of the PHP interpreter, which has been completely redesigned (Zend Engine 2), laying the groundwork for future enhancements. This article does not introduce the difference between PHP 4 and PHP 5, only a brief overview of what happens after PHP 5.0.

The following sections list the improvements in subsequent versions of PHP. Please note that only changes that affect PHP core are listed here. For a more complete description, see the Change Log for PHP 5 and PHP 7.

PHP 5.1

• Compiled variables
• Specialized Executor
• Real-path Cache
• Faster switch () statement handling
• Faster array functions
• Faster variable fetches
• Faster Magic Method Invocations

PHP 5.2

• New Memory Manager
• Optimized array/hashtable Copying
• Optimized require_once () and include_once () statements
• Small optimization on specific internal functions
• Improved compilation of Heredocs and compilation of interpolated strings

PHP 5.3

• Segmented VM Stack
• Stackless VMS
• Compile-time Constants Substitution
• Lazy Symbol Table Initialization
• Real-path Cache Improvement
• Improved PHP runtime speed and memory usage
• Faster language parsing
• Improved PHP binary size and code startup

PHP 5.4

• Delayed HashTable Allocation
• Constant tables
• Run-time binding Caches
• Interned Strings
• Improved the output layer
• Improved ternary operator performance when using arrays

PHP 5.5

• Improved VM calling convention
• Opcache Integration
• Other misc. optimizations to the Zend Engine

PHP 5.6

• Optimized empty string handling, minimizing the need to allocate new empty values

PHP 7.0

Most of the improvements listed below are related to Zend Engine:

• Core Data Structures re-factoring
• Better VM calling convention
• New Parameters Parsing API
• Yet another new memory manager
• Many improvements in VM executor
• Significantly reduced memory usage
• Improved __call () and __callstatic () functions
• Improved string concatenation
• Improved character searching in strings

PHP 7.1

• New SSA Based Optimization framework (embedded into Opcache)
• Global optimization of PHP bytecode based on type inference
• Highly specialized VM opcode handlers

PHP 8/Next Generation experimental JIT Branch edition

• Just-in-time compiling

How performance is measured

Benchmarking is different than simply running a Unix time command to measure the execution of a script. That's why I went through the following steps:

Configuring the System

First I set up a dedicated system with the following characteristics:

• One VPS with 1 2.4GHz virtual cores, 2GB RAM and two SSD drives, one for storing operating system data and the other for storing various Phpyuan dai ma, binary files and report outputs
• Debian wheezy operating system, version 3.2.82-1
• Gnu C Compiler version 4.9.2-10 (Debian Jessie release)
• Although the system is bundled with the GNU C compiler version 4.7.2, it needs to be upgraded to a newer version. The experimental JIT branch must be compiled with GNU c> = 4.8.

Compiling source code

Before you build the full release, run the configuration script with the following options:

2. --prefix=/usr/local/php
4. --disable-debug
6. --disable-phpdbg
8. --enable-mysqlnd
10. --enable-bcmath
12. --with-bz2=/usr
14. --enable-calendar
16. --with-curl
18. --enable-exif
20. --enable-fpm
22. --with-freetype-dir
24. --enable-ftp
26. --with-gd
28. --enable-gd-jis-conv
30. --enable-gd-native-ttf
32. --with-gettext=/usr
34. --with-gmp
36. --with-iconv
38. --enable-intl
40. --with-jpeg-dir
42. --enable-mbstring
44. --with-mcrypt
46. --with-openssl
48. --enable-pcntl
50. --with-pdo-mysql=mysqlnd
52. --with-png-dir
54. --with-recode=/usr
56. --enable-shmop
58. --enable-soap
60. --enable-sockets
62. --enable-sysvmsg
64. --enable-sysvsem
66. --enable-sysvshm
68. --enable-wddx
70. --with-xmlrpc
72. --with-xsl
74. --with-zlib=/usr
76. --enable-zip
78. --with-mysqli=mysqlnd

Note that some of the above options need to be disabled or replaced when compiling older versions, and not all extensions are available or can be compiled.

Run benchmark Tests

Each benchmark is run using the PHP CLI dedicated script, which follows these steps:

Use the Microtime () function to get the script execution time from the inside. After this modification, the baseline script will look like this:

1. <?php
2. $__start__ = microtime(true );
3. /***
4. Original benchmark script code here
5. ***/
6. fprintf(STDERR, microtime(True ) - $__start__);
7. ?>

Perform 2 runs to ensure that both the PHP executable and the benchmark script contents are in the operating system cache
Run the script 5 times and extract the minimum, maximum, and average run times, such as script reports. This article only shows the average run time, which is called "Script run Time".

The php.ini file looks like this:

1. Engine = On
2. Short_open_tag = Off
3. Realpath_cache_size = 2M
4. Max_execution_time = 86400
5. Memory_limit = 1024M
6. error_reporting = 0
7. display_errors = 0
8. display_startup_errors = 0
9. log_errors = 0
10. Default_charset = "UTF-8"
12. [Opcache]
13. Zend_extension=opcache.so
14. Opcache.enable=1
15. Opcache.enable_cli=1
16. Opcache.optimization_level=-1
17. Opcache.fast_shutdown=1
18. Opcache.validate_timestamps=1
19. Opcache.revalidate_freq=60
20. Opcache.use_cwd=1
21. opcache.max_accelerated_files=100000
22. Opcache.max_wasted_percentage=5
23. opcache.memory_consumption=128
24. Opcache.consistency_checks=0
25. Opcache.huge_code_pages=1
27. PHP 8/next only
28. Opcache.jit=35
29. opcache.jit_buffer_size=32m

Analyze Run Results

Use the Unix time command to clock, and the output looks like this:

1. $ Time PHP bench.php
2. real:0m1.96s
3. User:0m1.912s
4. sys:0m0.044s

The first value, real: is the time between the start of the command and the termination (when you return to the shell prompt).

The second value, User: Describes the time spent in user mode (in our case, this is the time spent in the PHP executable file).

Last value sys: Describes the time spent in the operating system (kernel) call. This value should be minimal, but if your code accesses a slow device the result will be larger. A heavy-duty operating system may also affect the values reported here.

On idle systems, the number (user + sys) should typically be very close to real. This is the case in the above example: User + sys = 1.956s,real is 1.960s. The 0.004s difference is not part of the current process: it simply means the extra time that the operating system takes to perform the task, such as scheduling.

The same script executes on a heavily loaded system, compiling 3 different versions of PHP in parallel:

1. $ Time PHP bench.php
2. Real:0m7.812s
3. user:0m2.02s
4. sys:0m0.101s

Here I see clearly that the heavy load on the system itself has a significant impact on the time spent (perhaps in system time).

That's why I keep an extra value in this benchmark, operating system overhead, which is the difference between the time of the call and (user + system) time.

During the pure CPU benchmark activity, I ensured that at more than 99% of the time, this value was strictly less than 100 milliseconds, even though the script would take a few 10 seconds to complete.

Conclusion

The purpose of this article is to give you an overview of the performance of a different version of PHP, starting with 5.0, to the latest version currently being developed, using a known set of benchmark scripts.

It also gives you a list of performance improvements that are addressed by each successive PHP version.

This article will be updated with the release of the new PHP version, and new benchmark results will be added in the future. I would also like to add some real-world PHP applications, such as WordPress benchmark test results.

Please feel free to leave a comment if you have any questions or if you find inaccuracies. At the same time, share this article with other developers who are interested in PHP performance.

PHP Performance Evolution (full evaluation of performance from PHP5.0 to PHP7.1)