Daily request billion web system PHP7 upgrade Practice ____php

The PHP7 upgrade practice of the web system which has requested billions of days

Author: Xu Hanbin, Wang Mehan, Liao Mao, Kuansuven, Liao, Hu Zemin

Source: CSDN

QQ member activity Operation Platform (AMS), is one of the important carriers of value-added operation Business of QQ member, and undertakes the web system of massive activity operation. AMS is a major use of PHP language implementation of the operating platform, CGI Day request about 300 million, peak reached 800 million. However, over the longer period of time, we have adopted a relatively old version of the basic software, is php5.2+apache2.0 (2008 technology). Especially since last year, with the rapid growth of the AMS business with the value-added services of QQ members, the performance pressure is getting bigger.

So, since May 2015, we have started planning the PHP low-level upgrade, the ultimate goal is to upgrade to PHP7. At that time, PHP7 was still in the research and development phase, and our discussion and preliminary research had already begun.

first, PHP7 study and pre-research

1. HHVM and JIT

Another important role in the 2015 optimization of PHP performance was the open source HHVM of Facebook (HipHop virtual MACHINE,HHVM is a Facebook open source PHP vm). HHVM using JIT (Just in Time, Just-in-time compilation is a software optimization technique that refers to compiling the bytecode as a machine code at runtime) and other techniques to make PHP code perform significantly better. It is rumored that the PHP5 version of native PHP code can be increased by 5-10 times the execution performance.

HHVM originated in Facebook, and many of the early-morning code for Facebook was developed using PHP, but as the business grew fast, PHP's execution efficiency became an increasingly obvious problem. To optimize execution efficiency, Facebook started using hiphop in 2008, a PHP execution engine that was originally designed to translate Fackbook's large number of PHP code into C + + to improve performance and conserve resources. PHP code that uses hiphop has several times the performance improvement. Later, Facebook will hiphop platform open source, gradually developed into the current HHVM.

HHVM becomes a PHP performance optimization solution, PHP7 is still in the research and development phase. Have seen some students for HHVM communication, performance can be a considerable upgrade, but the service and PHP syntax compatible with a certain cost. For a while, the JIT has become a very high voice of things, many technical students suggest that PHP7 should also be JIT to optimize performance.

July 2015, I attended the Chinese Phpcon, listened to Heosen about the PHP7 core technology sharing. In fact, in 2013, Heosen (PHP7 kernel developer) and Dmitry (one of the other PHP language kernel developers) once made a JIT attempt on the PHP5.5 version (not published). PHP5.5 's original implementation process, is the PHP code through lexical and grammatical analysis, compiled into opcode bytecode (format and assembly a bit like), then, the Zend engine read these opcode instructions, one by one parsing execution.

They introduced type inference (typeinf) after the opcode link, then generated the bytecodes by JIT and then executed.

As a result, the benchmark (test program) to get very good results, the implementation of JIT performance than PHP5.5 8 times times. However, when they put this optimization into the actual project WordPress (an open source blog project), but almost invisible performance improvement. The reason is that the code of the test project is relatively small, the machine code generated by the JIT is also small, and the real WordPress project generated machine code is too large, causing CPU cache Hit rate drop (CPU cached Miss).

In short, JIT is not in every scene is a powerful tool, and out of the business scene performance test results are not necessarily representative.

From the official release of WordPress PHP7 and HHVM Performance comparison can be seen, the two are basically at the same level.

Performance optimization of 2.PHP7

PHP7 is a relatively low-level upgrade, compared to the PHP5.6 change is larger, and the performance optimization level, can be summarized as follows:

(1) Transforming the base variable from struct (structure) to Union (consortium), saving memory space and indirectly reducing CPU overhead in memory allocation and management.

(2) Some basic variables (Zend_array, zend_string, etc.) use the way of continuous allocation of memory space to reduce the probability of the CPU Cache miss. CPU access to data from the CPU cache and from memory, they can be as high as 100 times times the difference in efficiency. To give an approximate example, the system from the memory read data and read data from the disk is very different efficiency, CPU Cache miss similar to a missing page interrupt.

(3) Through macro definition and inline function (inline), let the compiler complete some work ahead of time. No need to allocate memory when the program is running, can realize function of similar function, but there is no pressure stack and stack overhead of function call, the efficiency will be higher.

More details about the introduction of PHP7, interested students can see: "PHP7 Innovation and performance optimization"
the background of 3.AMS platform technology selection

In terms of improving PHP performance, it is possible to choose the HHVM that can be used directly in 2015 or the PHP7 of the official edition at the end of 2015. Member AMs is a large access level of a web system, after four years of continuous upgrades and optimization, accumulated more than 800 business functional components, as well as a variety of PHP-written public base libraries and scripts, the size of the code is also relatively large.

Our PHP version of the Code for backward-compatible requirements is relatively high, so, in our business scenario, PHP7 good grammar backward compatibility, is what we need. Therefore, we choose to PHP7 as the upgrade scheme.

Ii. risks and challenges faced by PHP7 upgrades

For a large public Web service already online, the basic public software upgrades, usually a thankless job, do well, not necessarily be perceived by everyone, but, upgrade out of the problem, you need to bear a heavier responsibility. In order to minimize the risk of escalation, we must first understand the challenges and risks of our upgrades.

We then sorted out the upgrade challenge and risk list:

(1) Apache2.0 and PHP5.2 of the two 2008-2009-year version of the basic software is older, upgrade to Apache2.4 and PHP7, version upgrade span is relatively large, time span of 7-8 years, therefore, the compatibility of the challenge is higher. In fact, our company's current network of PHP services, many are stuck in the PHP5.2 and PHP5.3 version, the version is low.

(2) AMs Extensive use of Tphplib expansion, Tphplib very early in the company no one to maintain, this extension is only PHP5.3 and PHP5.2 compiled so version, and, some extensions do not support thread safety. Thread-safe is supported because our previous Apache used the prefork mode, And we want to be able to use the Apache2.4 event pattern (in 2014, after Prefork and worker, the introduction of a multiprogramming threading management model to support high concurrency, a better performance).

(3) syntax compatibility problem, from PHP5.2 to PHP7 span is too large, even if the PHP official claims to do in backward compatibility to do 99%, but, our code scale is larger, it is still an unknown risk.

(4) The risk of new software to upgrade the Apache and PHP basic software to the latest version, and some of these versions of the functionality may be unknown risks and defects.

Some students may suggest that the use of nginx will be a better choice, indeed, compared Nginx and Apache performance in high concurrency, nginx performance more excellent. But in the case of PHP CGI, there is no big gap between NGINX+PHP-FTPM and apache+mod_php. On the other hand, we accumulate more technical familiarity and experience because of the long term use of Apache, so it may not be the best choice, but it is a more appropriate choice for our business scenario.

third, the version upgrade implementation process

1. High-SPAN version upgrade mode

From a 2008-year Apache2.0 direct upgrade to the 2016 Apache2.4, this span is too large