PHP engine Survey

Source: Internet
Author: User
Tags hhvm
This survey was conducted in October 2013 with the goal of finding a better PHP engine to replace the PHP5.2 currently used by Baidu's product lines. Environment Description machine environment: cpu: Intel (R) Xeon (R) CPUE5-26200@2.00GHz, 12 cores. Memory: 64 GB engine: php5.2.17 (the version used by Baidu at that time) php5.5.4 (the latest version at that time)

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

Machine environment:

  • Cpu: Intel (R) Xeon (R) CPU E5-2620 0 @ 2.00 GHz, 12 cores.
  • Memory: 64 GB

Engine:

  1. Php 5.2.17 (the version used by Baidu at that time)
  2. Php 5.5.4 (Latest Version)
  3. Hhvm 2.3-dev (the latest version)

To be fair, all three engines adopt the-O2 compilation optimization option.

Accelerator:

  1. Php5.2.17: Using eaccelerator
  2. Php5.5.4: eacc is not available and zend opcache is used.
  3. Hhvm: built-in opcode cache with jit Enabled

Extension:

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:

  • Small. php: https://github.com/php/php-src/blob/master/Zend/bench.php
  • Micro_bench.php: https://github.com/php/php-src/blob/master/Zend/micro_bench.php
  • Test script bench_third.php provided by a third party: http://www.php-benchmark-script.com/

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
Php5.2 3.6 ms 50% 1900
Php5.5 2.9 ms 60% 2500
Hhvm 2.0 ms 60% 3900

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:

  1. Remove unnecessary encoding conversions and reduce15ms
  2. Remove unnecessary warning logs and reduce the time consumption.4.3ms
  3. Improve the implementation of the xss transcoding function to reduce time consumption1.8ms

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:

  1. Several Functions repeatedly calculate the same information in each request. After the apc cache is added, the time consumed is reduced.16ms
  2. The user-defined errorHandler reduces the time consumed after being removed.7ms
  3. Remove some debug logs to reduce time consumption1ms

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.
Php5.5 1 1
Hhvm 1 1

All differences are shown here:

  • Http://www.php.net/manual/en/migration53.php
  • Http://www.php.net/manual/en/migration54.php
  • Http://www.php.net/manual/en/migration55.php
Implementation differences between hhvm and zend Engine

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.
2 0

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:

  1. Upgrade to the latest version. Five
  2. Solve the problem by modifying the code.
Hhvm

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

  1. Compile extended idl files (in json format)
  2. Automatically generate code framework based on idl
  3. Fill in the code framework to implement your own logic
  4. Re-compile hhvm

Disadvantages:

  1. The existing Baidu extension needs to be modified again. It must be rewritten to obtain input parameters, return results, and other APIs called to php. h. This is the main cost.
  2. At present, the api of hhvm is not stable. The extensions written in 2.1.0 cannot be compiled in 2.2.0 ..

Advantages:

  1. Writing new extensions is more convenient than writing in zend. hhvm provides APIs similar to boost variant, making it easy to process input and output.

Ii. Dynamic Loading (HNI: hhvm native interface)

  1. Compile function declaration. php (syntax is similar to php)
  2. Compile function implementation. cpp
  3. Hphpize & cmake. & make, must be compiled separately for extension

Dynamic Loading is more convenient, so it is recommended to write extensions in this way.

Iii. ZendCompatLayer

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.

  1. Try to enable ZendCompatLayer and compile the yaml extension in the package to confirm that ZendCompatLayer is available.
  2. I tried to use ZendCompatLayer to Compile two Baidu extensions and found many problems, for example, functions such as missing functions, ini loading, minit/rinit calling, incompatible gcc versions, and multi-threaded environments are not supported by the original extension. After various modifications to hhvm and extended code, it is easy to run, but the cost is high and the stability is difficult to guarantee.
  3. The performance of ZendCompatLayer is tested. An array containing string, int, and nested arrays is used to repeatedly call a Baidu extension for packaging and unpackaging. The result is as follows:
Time consumed Implementation Method
199 MS HNI
769 MS HNI + ZendCompat
348 MS Php5.2

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:

  • Http://www.php.net/manual/en/migration53.php
  • Http://www.php.net/manual/en/migration54.php
  • Http://www.php.net/manual/en/migration55.php

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:

  1. StartupDocument: You can execute this file at startup, perform global initialization in this file, and pass the result variable to the worker thread through apc. In this way, we put some repeated initialization work in this file to avoid the same work for every request.
  2. ThreadDocuments: You can use a background thread to execute a file and perform operations such as information collection and Scheduled Update. This prevents the execution of corresponding processes in each request from affecting the response time of online requests.
  3. Pagelet Server/Xbox Server: A sub-Server can be started. The sub-Server maintains a thread pool, and the master Server can distribute some computing tasks to the sub-Server for asynchronous execution to achieve parallelization. I tried this function. It is really convenient to use the xbox server to conveniently implement the function of calling backend services in parallel, and this mechanism is common, not only can backend calls be in parallel, local computing can also be performed in parallel. Can we consider rendering the template in parallel? Haha.
  4. Multi-threaded architecture: this is not a function, but the natural convenience that the hhvm multi-threaded architecture brings to us. Because in the same process, Memory sharing is very convenient and the access speed is faster, and some functions such as the connection pool can also be implemented.

For more information about the above functions, see:

  • Https://github.com/facebook/hhvm/blob/master/hphp/doc/server.documents
  • Https://github.com/facebook/hhvm/blob/master/hphp/doc/threading
Developer support

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.

UPDATE

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:

  1. Your server costs are high now, and you want to save costs, or your resources are insufficient due to sustained traffic growth.
  2. You need to improve performance transparently.
  3. You do not have any self-built extensions, or you have time to migrate extensions (the cost of migrating extensions to HHVM is very low and will be introduced later)
  4. You want to use the Hack Language
  5. Or you want to try new technologies

Similarly, this also hasMigration not recommendedReason for HHVM:

  1. Your servers and traffic are small.
  2. Your business is stable and has no performance requirements.
  3. You are local tyrants, machines are piled up at will, and the budget is not enough

There are also some questions:

  • Q: Some people have mentioned the O & M cost. Is HHVM really difficult to maintain?
  • 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.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.