PHP 7 performance optimization (to deal with high server concurrency)

Opcache

1. Opcache principle

Request request (Nginx, Apache, Cli, etc.) → Zend engine reads .php file → scans its dictionaries and expressions → parses file → creates computer code to execute (called Opcode) → finally executes Opcode → Response returns

The above steps will be executed every time the PHP script is requested. If the PHP source code does not change, then the Opcode will not change. Obviously, there is no need to regenerate the Opcode every time. Combined with the ubiquitous caching mechanism in the Web, we can cache the Opcode. , wouldn't it be faster to directly access the cached Opcode in the future? The flow chart after enabling the Opcode cache is as follows:

The purpose of the Opcode cache is to avoid repeated compilation and reduce CPU and memory overhead

2. Opcache configuration

// Load opcache (need to confirm that the opcache extension is installed)
zend_extension=opcache.so
// enable opcache
opcache.enable = 1
// OPcache shared memory storage size, in MB
opcache.memory_consumption=1024 // 1G
// PHP uses something called string persistence, which defaults to 4MB
opcache.interned_strings_buffer=32
// This option is used to control the maximum number of PHP files that can be cached in memory. This option must be set large enough, greater than the sum of all PHP files in your project
opcache.max_accelerated_files=80000
// Set the expiration time of the cache (in seconds), if it is 0, check it every time
opcache.revalidate_freq=3
// Literally "allow faster shutdown"
opcache.fast_shutdown=1
// In the CLI environment, PHP enables OPcache
opcache.enable_cli=1

HugePage

1. Principle of HugePage

By enabling this feature, PHP7 will "move" its TEXT segment (executive body) to Huagepage. In the previous test, we could see a 2%~3% increase in QPS on Wordpress stably.
Regarding what Hugepage is, simply put, the default memory is paged by 4KB, and the virtual address and memory address need to be converted, and this conversion is to look up the table, and the CPU will build TLB in order to speed up the table lookup process. (Translation Lookaside Buffer), it is obvious that if the virtual page is smaller, the number of entries in the table will be more, and the TLB size is limited, the more entries the TLB's Cache Miss will be higher, so if we can enable the larger The memory page can indirectly reduce this TLB Cache Miss. As for the detailed introduction, I will not go into details after a lot of Google searches. Here, I will mainly explain how to enable this new feature to bring about significant performance improvement.

2. HugePage configuration

$ sudo sysctl vm.nr_hugepages=512 // The bigger the better, it will take up a lot of memory

Allocate 512 reserved hugepages:

cat /proc/meminfo | grep Huge
AnonHugePages: 106496 kB
HugePages_Total: 512
HugePages_Free: 504
HugePages_Rsvd: 27
HugePages_Surp: 0
Hugepagesize: 2048 kB

Then add in php.ini

opcache.huge_code_pages=1

Opcache file cache

1. Introduction to Opcache file cache

Using opcache to store compiled php files as files, to achieve php source code protection and script acceleration, will significantly improve performance

2. Opcache file cache configuration

Add in php.ini

opcache.file_cache=/tmp

In this way, PHP will cache some binary export files of Opcode in the /tmp directory, which can exist across the PHP life cycle.

Comparison test

Before optimization

• cpu: 95%-96%
• Memory: 2G/16G
• 10 minutes 4W concurrent
• Failure rate: 24%

Aggregated reports

transactions per second

Optimized

• cpu: 20%-40%
• Memory: 5.8G/16G (here I set HugePage to 2048)
• 10 minutes 4W concurrent
• Failure rate: 0%