A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
This survey was conducted in October 2013 with the goal of finding a better PHP engine to replace the PHP 5.2 currently used by Baidu's product lines. Environment Description machine environment: cpu: Intel (R) Xeon (R) CPU E5-2620 0 @ 2.00 GHz, 12 cores. Memory: 64 GB engine: php 5.2.17 (the version used by Baidu at that time) php 5.5.4 (the latest version at that time)Introduction
This survey was conducted in October 2013 with the goal of finding a better PHP engine to replace the PHP 5.2 currently used by Baidu's product lines.Environment Description
To be fair, all three engines adopt the-O2 compilation optimization option.
Currently, Baidu extensions are rarely transplanted to hhvm, so to be fair, other Baidu extensions are also disabled in php5.2 and php5.5, and are implemented in php-only mode, practice has proved that the performance of pure php is not greatly reduced.Performance
Different scenarios are used to compare the performance of the PHP engine.Scenario 1: Pure cpu computing
Use the test script officially provided by php:
The test results are as follows:
|Engine||Runtime. php time consumption||Micro_bench.php time consumption||Bench_third.php time consumption|
|Php5.2||6.692 s||41.890 s||9.226 s|
|Php5.5||3.609 s||14.972 s||5.893 s|
|Hhvm||0.579 s||5.832 s||2.869 s|
Analysis: Previous php versions have optimized performance, so php5.5 has obvious advantages over php5.2 in pure cpu computing. Hhvm uses the jit mechanism to convert php into local code for execution, so it is much faster than php5.5 that executes opcode.
Conclusion: for pure cpu computing, hhvm> php5.5> php5.2.Scenario 2: simple http service
A simple http service is a service composed of a simple php logic interface layer and a backend C Module (or general storage). Here, a practical simple service inside Baidu is used as an example.
A simple performance test is conducted. The client concurrency is 10. The client and service are deployed on the same machine, and the service and the backend C module are deployed on different machines. The result is as follows:
|Engine||Average Response Time||Cpu idle||Qps|
Analysis: for simple http Services, there is also a part of logical computing. In addition, hhvm is the integration of webserver and php engine, without the overhead of webserver-> php, therefore, there are more obvious advantages in response time and qps. Because the response time of the C Module's backend itself is short (1 ms), the overall response time of different engines varies significantly.
Conclusion: for simple http Services, hhvm> php5.5> php5.2 on qps, remove the backend service time in response time, which is also hhvm> php5.5> php5.2.Scenario 3: product front-end UI
Here we use the latest version of the web interface to access the backend.
The test result is as follows:
|Engine||Overall time consumption||Time consumed in addition to accessing the backend||Idle||Qps|
|Php5.2||520 ms||127 ms||50%||40|
|Php5.5||500 ms||107 ms||45%||45|
|Hhvm||470 ms||72 ms||65%||50|
Analysis: the ui is mostly consumed by backend service access, which does not work for the engine. On the other hand, in addition to backend services, the time consumption is also high, which consumes a large amount of cpu, resulting in a low qps.
Obviously, this effect is not very consistent with our expectations. To achieve the desired qps, we need to find a way to further reduce the time consumption besides the backend.
First, we run xhprof in PHP5.2 to find some time-consuming functions and optimize them:
Through the optimization above, the time consumption of the ui in HHVM is reduced to 52 ms, and the template time is 34 ms. But this is still unsatisfactory. How can we further optimize it?
Since the above xhprof is executed under PHP5.2, what if we try to run xhprof directly under HHVM? The results show that the xhprof results under HHVM are very different from those under PHP5.2, and some new optimization points are found and optimized:
Through the above optimization, we reduced the time consumption of the ui under HHVM to 26 ms. So what if the same optimization works under PHP5.2 or PHP5.5?
|Engine||Before Optimization||After business Optimization|
|Php5.2||127 ms||103 ms|
|Php5.5||107 ms||87 ms|
|Hhvm||72 ms||26 ms|
Disappointing... The reason is that the time consumption in php is quite scattered in the distribution of various functions, and it is difficult to greatly improve even when optimizing individual functions.
In hhvm, due to the high performance of the engine itself, some previously implemented unreasonable and time-consuming functions are highlighted. Therefore, these functions are optimized, more Obvious results can be achieved.
Conclusion: for the front-end UI of the product, the engine can optimize the response time and qps to a certain extent. hhvm> php5.5> php5.2, for example, combined with some optimization for hhvm, this greatly improves qps under hhvm.Compatibility language compatibility
The language compatibility comes from two aspects:Syntax differences of different php versions
Hhvm is based on the php5.4 syntax standard. Therefore, there are syntax differences between hhvm and php5.5 and the php5.5.5.
Currently, the number of differences is as follows:
|Engine||Impact processing result||The result is not affected. Press warning.|
All differences are shown here:
Because there are two sets of different implementations, there are also differences between hhvm and zend engine.
The number of differences currently encountered is as follows:
|Impact processing result||The result is not affected. Press warning.|
The hhvm documentation also mentions some differences: https://github.com/facebook/hhvm/blob/master/hphp/doc/inconsistencies
Conclusion: In general, there are some differences between hhvm and php5.5 in terms of language and php5.2, and the processing results are affected. However, most of the differences will result in the execution of fatal or warning. We only need to modify the code according to the corresponding prompts, and the modification cost is not large.Extended compatibility php5.5
Compile the extensions used by Baidu in php5.5. Most of the extensions can be compiled successfully. A few compilation failures:
Hhvm has many common third-party extensions built in, so there is basically no need to migrate third-party extensions. The main consideration is Baidu expansion migration.
There are two ways to compile and extend hhvm:
I. Static Compilation
Ii. Dynamic Loading (HNI: hhvm native interface)
Dynamic Loading is more convenient, so it is recommended to write extensions in this way.
Hhvm is implementing a ZendCompatLayer, which is a layer compatible with zend extensions. It implements zend engine APIs to facilitate the migration of existing extensions to hhvm. See specific: https://github.com/facebook/hhvm/blob/master/hphp/doc/php.extension.compat.layer
According to the description, zend extensions can be migrated to hhvm without too much modification.
|Time consumed||Implementation Method|
|769 MS||HNI + ZendCompat|
Conclusion: ZendCompatLayer is not complete yet, and many APIs are not implemented yet. In addition, the performance is still poor. We recommend that you use hhvm native mode for performance-demanding extensions, while ZendCompatLayer can be used for long-tail extensions, reduce migration and maintenance costs.
Conclusion: php5.5 has good compatibility with extensions, and the Migration cost is not high. Hhvm currently has a high cost of expansion and migration. However, if ZendCompatLayer is available, the Migration cost can be greatly reduced. You can wait for ZendCompatLayer to complete and then perform further research.System compatibility
Php5.5 has no requirements on the operating system.
Hhvm has high requirements on the system and needs to be compiled and run in ubuntu/centos. Most Baidu machines do not meet the requirements ..
However, after research, we found that we can package the so method to enable hhvm to run on Baidu machines. The tests above were conducted on Baidu machines and no problems were found.
Based on the same principle, by packaging the dependency so and header files, hhvm can also be compiled on Baidu machine and has been compiled successfully.
In terms of kernel, hhvm requires at least 2.6.32 systems, and most Baidu systems meet the requirements.
Conclusion: php5.5 and hhvm have no problems in system compatibility.Configure compatibility
Php5.5 for php. ini is compatible, but the php-fpm.conf is changed to ini format, the original php-fpm.conf needs to be modified, and php-fpm is also compiled into a separate executable file, instead of sharing it with php-cgi.
Hhvm configuration is a new hdf format, and its configuration items are different. Different configuration items may not be found for every php. ini configuration, but common ones are. The new version of hhvm also supports specifying the php. ini file, but it still does not support all configuration items.
Hhvm is the integration of webserver and php. Common functions of webserver, such as rewrite, simple attack prevention, proxy, log, and static file services are also available. Therefore, the relevant configurations of webserver must also be in the hhvm configuration format. But now HHVM also supports fastcgi mode, so this is no longer a problem.
Conclusion: php5.5 is better in configuration compatibility. However, there are not many configuration files, and the cost of manual transformation is not very high, so this problem is not big.New Features
Php adds many new features from 5.3 to 5.5. For details, see:
In general, it can be summarized as more flexible syntax and richer functions.
The syntax of hhvm is based on 5.4, and the library support is not as rich as php5.5. However, hhvm provides several functions, which may be of great help to performance optimization:
For more information about the above functions, see:
Php5.5 is well supported by developers, with comprehensive documentation and stable APIs.
In contrast, the developer support of hhvm is still relatively weak, and there are very few documents. In many places, you have to find your own solutions and the api is not stable yet, but the community of hhvm is very active, many people in github are mentioning issue and patch. The official hhvm team is also very powerful, and the iteration speed is very fast. A stable version is released every eight weeks.Overall conclusion
In general, php5.5 is used to improve the performance and reduce the migration cost.
With hhvm, the performance will be greatly improved, but the migration cost will be large, mainly because of the expansion cost.
The conclusion here is obvious that most of Baidu's product lines use HHVM, because we believe that resource conservation is very profitable for such large-scale applications.
After reading this, you may have questions about whether you want to upgrade to HHVM? Do you want to know how PHP 7 compares?
Here is youMigration requiredReason for HHVM:
Similarly, this also hasMigration not recommendedReason for HHVM:
There are also some questions:
A: HHVM multithreading model is relatively unstable PHP-FPM, but there are A lot of process daemon solution can be A good solution, this is not A problem, in view of Baidu's current O & M is relatively stable.
Q: Isn't PHP7 a good performance? Why migrate to HHVM?
A: First, PHP 7 is still under development. First, there are risks of migrating A large version. At least it is unreliable to consider. If you are willing to wait, you can wait until PHP 7 is available for comparison. Check which one is more suitable for you. At this stage, HHVM is a better choice than PHP.
Do Your Own Benchmarking)
If you decide to migrate, we recommend that you evaluate your business before you begin to ensure that the benefits are within the expected range.
Original article address: PHP engine survey, thanks to the original author for sharing.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service