PHP 7 was first released back on 03 Dec 2015. Yes, I’m sure, it’s been around a while! The PHP team encouraged upgrading to PHP 7, hailing its improvements such as being twice as fast, consistent 64-bit support, removal of old and unsupported SAPIs and extensions, improved fatal error resistance, to name a few.
A few years 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 60% of PHP versions in use. PHP still holds almost 80% market share of server-side programming languages for websites.
At the end of 2021, PHP 7.4 will lose active support. So what are your thoughts? Have you performed a PHP 8 Compatibility Check? Are you ready to upgrade? What are some of the standout features of PHP 8? Let’s have a look.
Table of Contents:
PHP 8 compatibility check with these tools
There are some tools available that automate the process of checking your scripts for PHP 8 compatibility. Here’s a couple that I can recommend.
- phan – a static analyzer. PHP 8 checker.
- phpstan – PHP Static Analysis and compatibility check.
- PHP Compatibility checker for PHP_CodeSniffer.
- PHP-Parallel-Lint checks syntax of PHP files.
- There’s also PHPStorm for developers.
- Upgrading doc in the PHP 8’s Github branch.
- Migrating from PHP 7.4.x to PHP 8.0.x.
For example, you run phan with something like:
phan --project-root-directory --progress-bar -o phan.out
PHP 8 benchmarks
Benchmark image via AWS Compute Blog.
We are well aware that PHP 7 was at least 2x faster than PHP 5.6. In PHP 7 vs. PHP 8, the improvements are not that drastic but based on many benchmarks, it’s more than enough to be worthwhile. In addition to speed, PHP 8.0 delivers new features such as the much anticipated Just In Time (JIT) compiler, other performance optimizations, and built-in/core JSON support, to name a few.
PHP 8 Performance tips – php.ini config tweaks
php.ini config example.
First things first, something you probably already have enabled in PHP 7: OPcache [Also read: PHP Benchmarks: OPcache vs. OPcache w/ Performance Tweaks] This may be set in php.ini config file or via its own opcache.ini file (ex. /etc/php/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 PHP OPcache is enabled, it’s always nice to view its run-time stats to ensure that everything runs smoothly (ex. no OOM restarts). Also, see preloading of OPcache.
Screenshot from CacheTool, a CLI OPcache manager. (PHP restarted after upgrade)
No command line access? Use an OPcache Control Panel.
Enable PHP 8 JIT
PHP JIT is implemented as part of OPcache. You should already have OPcache enabled via php.ini/opcache.ini:
Next, you’ll want to add the following to enable JIT:
When enabled (remember to restart PHP), the native code of PHP files is stored in an additional region of OPcache’s shared memory.
For high traffic web servers running PHP, you can squeeze out additional throughput by setting PHP realpath_cache_size ‘correctly.’
realpath_cache_size = 256k realpath_cache_ttl = 300
Turn off MySQL statistics in php.ini.
Check your php.ini and make sure on your production servers, both of these settings
mysqlnd.collect_memory_statistics are disabled. It should always be disabled unless you have a specific reason to enable it. You can view MySQL run-time statistics using the MySQL command line (ex. show status;). Also related to MySQL, depending on your scripts, you can set up PHP Redis and/or Memcached to reduce MySQL queries.
mysqlnd.collect_statistics = Off mysqlnd.collect_memory_statistics = 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 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). The recommended setting for this is Off or 4096, depending on your application. 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.
output_buffering = 4096
We are all well aware that it’s important to keep PHP up to date from a security standpoint. In addition to security, faster PHP performance is significant because end-users are becoming less tolerant of slow websites and applications. We have covered the tools available to check PHP 8 compatibility, and I will keep adding more. Also, according to various benchmarks around the web, PHP 8 is considerably faster than PHP 7. As such, in closing, it’s time to upgrade your applications to PHP 8!