PHP 5.6 EOL (End of Life) – PHP 7 Compatibility Check

Summary: PHP 7.3 benchmark, how to check your PHP scripts/apps for PHP 7 compatibility, upgrade to PHP 7 ASAP, confirm OpCache is enabled/monitored and some php.ini optimization tweaks.

PHP 5.6 and PHP 7.0 to hit EOL this year! reached EOL last Year! (2018)

PHP 5.6 was first released back in 2014, with alpha 1 released in January 2014. Due to major performance improvements (phpng then merged into PHP 7), by December 2015 the PHP team started to encourage upgrading to PHP 7. Hailing it’s improvements such as being twice as fast, consistent 64-bit support, removal of old and unsupported SAPIs and extensions, improved fatal error resistance, etc.

A year ago, I wrote the short article 80% of the web powered by PHP. [But 90% of PHP sites run PHP5]. Since then, we’ve had some movement on this front. PHP 7 now accounts for more than 15% of PHP versions in use. That’s up from 3% a year ago. PHP still holds about 80% market share of server-side programming languages for websites.

At the end of 2018 both PHP 5.6 and PHP 7.0 hit EOL / support. So what are your thoughts? Do you think there will be a mad dash to upgrade to PHP 7? As it was the final PHP 5 release, end of life support for PHP 5.6 was already extended. Active support ran for an additional four months (ended 19 Jan 2017), while the security fix period was doubled from one to two years. (ends ended 31 Dec 2018)

PHP 7.3 so far up to 25% faster than PHP 7.0

We are well aware that PHP 7 is at least 2x faster than PHP 5.6. However, have a look at the below Phoronix benchmark at just how much PHP 7 has improved since it’s first release at the end of 2015. PHP 7.3 Alpha is quite a bit faster than previous versions of PHP 7. PHP 7.3, so far, is up to 3x faster than PHP 5.6! With what should be an increased rate of migrations to PHP 7, we are eagerly awaiting at a faster internet on this merit alone.

How to check if your PHP scripts are PHP 7 compatible

There are a few tools/scripts which automate the process of checking PHP 7 compatibility. Prior to writing this, I used php7cc (project no longer supported).There are however, a few other active projects:

• php7mar – PHP 7 Migration Assistant Report (MAR). (Recommended)
• phan – a static analyzer. PHP 7 checker.
• phpstan – PHP Static Analysis and compatibility check.
• There’s also PHPStorm for developers.

For example you run phan with something like:

phan --project-root-directory --progress-bar -o phan.out

or for php7mar:

php mar.php -f="/path/to/project/root/" -r="/path/to/output/"

PHP 7 Performance tips – (php.ini config tweaks)

php.ini config example

First things first, this is something you probably already have enabled: OpCache [Read: PHP Benchmarks: OPcache vs OPcache w/ Performance Tweaks] This may set in php.ini config file or in it’s own opcache.ini file (ex. /etc/php/7.2/fpm/conf.d/10-opcache.ini). You can check if OpCache is enabled from phpinfo() output, or from command line using: php -v or php -i | grep opcache.enable. After you’ve confirmed that PHP OpCache is enabled, its always nice to view it’s run-time stats, just to be sure everything is running smoothly (no restarts of OpCache for example). Below is a screenshot of the OpCache control panel for this blog (php restarted after upgrade from PHP 7.1 to PHP 7.2). Also see: oPcache Control Panels for control panel options.

realpath_cache_size = 256k
realpath_cache_ttl = 300

For high traffic web servers running PHP, you can squeeze out additional throughput by seting PHP realpath_cache_size ‘correctly’.

mysqlnd.collect_statistics = Off
mysqlnd.collect_memory_statistics = Off

Check your php.ini and make sure on your production severs, both of these settings mysqlnd.collect_statistics and mysqlnd.collect_memory_statistics are disabled. Should be always disabled unless you have a specific reason to enable. You can view MySQL run-time statistics using MySQL command line (ex. show status;). Also related to MySQL, depending on your scripts, it may help setup PHP Redis and/or Memcached to reduce MySQL queries.

output_buffering = Off

PHP’s output buffer controls how HTML is sent to the browser. When set to ‘Off’ (the default), HTML is sent to the browser immediately while PHP processes through your scripts. With output buffering set to ‘On’, PHP output buffer saves what would have otherwise hit the web browser into a single string in a buffer. You can also set a specific output_buffering size (ex. output_buffering=4096). Turning on output buffering decreases the amount of time it takes to download and render HTML because it’s not being sent to the browser in pieces as PHP processes the HTML. The recommended setting for this is Off or 4096, depending on your application/scripts. For example, if the html head contains css or js (not a good practice), the browser could be paralleling those downloads with output_buffering enabled.

In the meantime, lets keep an eye on PHP 7.3 while ensuring we migrate all assets from PHP 5.6 to PHP 7.

Linux distros that default to PHP 7.* are:

Arch Linux = PHP 7.2 PHP 7.3
Fedora 28 = PHP 7.2
Ubuntu 18.04 LTS = PHP 7.2
Fedora 27 = PHP 7.1
Ubuntu 17.10 = PHP 7.1
Ubuntu 16.04 LTS = PHP 7.0
Debian 9 = PHP 7.0
openSUSE Tumbleweed = PHP 7.0
Get PHP 7.2 for RHEL or CentOS via EPEL.

Updated: January 23rd 2019