We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.

Site slower with PHP 7.2 than PHP 5.6

I've switched my biggest website (on Phalcon 3.4.2) from PHP 5.6 to PHP 7.2 and I find that it has become slower. I'd expected this to make the site faster, so I wonder why this is.

The site is on CentOS 6.10 with DirectAdmin. I used DirectAdmin to swith PHP versions, and I had updated the PHP versions and Apache 2.4 before the switch, using DirectAdmin's Custombuild.

  • PHP 5.6 is mod_php
  • PHP 7.2 is FPM

On a page with average functionality, I measured the time to generate the page in the front controller, right before loading the config.yaml and at the end, using the microtime() function, with a simple profiler class of my own.

On PHP 5.6 I had page generation times of 11 .. 17 ms. On PHP 7.2 times of 20 .. 33 ms. So, about doubled times, while I had expected a reduction.

Why is that? Can I do something about it?

Hard to tell, i only had either increase or stagnation in performance after switching to 7.2. Maybe you haven't enabled opcache or something similar?

Yes, I forgot to enable opcache.

Loading with zend_extension doesn't seem to work, so I'll need to find out why that is.

edited Feb '19

I'm getting a segmentation fault when trying to load opcache. PHP fails to load:

Starting php-fpm72: /etc/init.d/php-fpm72: line 50: 16166 Segmentation fault $BIN $OPTS

failed

Apparently I'm not the first to have this problem: https://github.com/phalcon/cphalcon/issues/13674 The suggested solution of moving from CentOS 6 to 7 seems a little drastic.

You skipped to migrate project from PHP 5.x to PHP 7.0 at first place? So giant leap from 5.x to 7.2 can cause lot of things go wrong. And doesn't have to do anything with Phalcon per se.

Also you have switched SAPI, not only PHP version. Which is also a drastic change on it's own. And that's something you do only using exact same PHP version.

And bottomline is you're using DirectAdmin. Also could be a potential source of problems.

So - yeah, CentOS upgrade/fresh install is the way to go. If you really must use RPM system....

What I would do instead - make it work on PHP 7.0 first, get rid of Apache in favour of nginx (PHP-FPM), make it all work there and only then migrate to latest PHP versions.

edited Feb '19

Well, I've tested with PHP 7.1 and PHP 7.2 on my development system, and with a few changes in the PHP code, that didn't cause any problems. I don't see why I wouldn't switch to PHP 7.2 on my production system.

My choice to have PHP-FPM for now has to do with the way that Directadmin can switch PHP versions. It doesn't allow to have multiple PHP versions that are on mod_php, and at the moment I want to have the option to switch back to PHP 5.6 on mod_php.

I did my research, and I know that nginx and FastCGI can only give a performance increase if the webpages load a large number of files (images, javascript and css), and that just isn't the case, as my sites are very lightweight in that respect. PHP on FastCGI is slower than mod_php, because of the extra overhead. So, no nginx for me, and the PHP-FPM is temporary. I will switch to mod_php when I'm certain that things work fine on PHP 7.2 FMP, and I won't need the option to switch back to PHP 5.6 on mod_php anymore.

edited Feb '19

PHP on FastCGI is slower than mod_php, because of the extra overhead.

IDK whenever you are referring here to PHP-FPM which runs as a standalone FastCGI server or traditional FastCGI SAPI from Apache's perspective?

PHP-FPM is all about removing initialization costs as PHP-fpm pre-starts several PHP processes, ready to process requests, and have them sleep until requests come in - which means it can respond much faster than traditional CGI, because PHP is already running when requests come, as opposed to traditional CGI, where a new PHP process is started for each request, also php-fpm doesn't shut down the PHP process after processing requests but keep reusing the same processes. - with 0 overhead of starting and stopping processes, php-fpm responds much faster. starting & stopping processes takes time.

So if that overhead what you did research on was really the case all large deployments would still be running on Apache, but they don't and static files are least of concern.

The bottomline is - if you don't need/want to change SAPI that's OK - but be consistent then, use same SAPI and see how it works (your project). Also, you should never switch PHP versions and other stuff on a live server before testing it through on a dev server!

I have no interest in switching to nginx, nor in discussing the pros and cons of PHP-FPM any further. I'm staying with the setup I have, and only consider switching to CentOS 7 if there is really no other way to get rid of the segfaults with OpCache.

Regarding the segfault, that particular error should be reported to the centos php-opcache package maintainers.

The segfault is there when I have OpCache enabled, but could be caused by a problem in another PHP extension. The thread about cphalcon issue 13674 suggests that the problem might be in Phalcon 3.4.2-2, and is solved in Phalcon 3.4.2-5 or later.

So, I would like to upgrade Phalcon to the current 3.4.2-7, but that version is not available with yum for CentOS 6 (it is for CentOS 7). There is also no tag in the git repository for it that I could use (tag 'v3.4.2' is 3.4.2-1, as far as I can see).

Could someone answer my question about this in this thread, on how to get Phalcon 3.4.2-7 using the git repository?

I installed the new Phalcon 3.4.3 (using the repository with git checkout tags/v3.4.3), but enabling OpCache still gives a segfault.

Starting php-fpm72: /etc/init.d/php-fpm72: line 50: 8715 Segmentation fault $BIN $OPTS

With some googling, I found that it is likely that the segfault problem is really in PHP 7.2 FPM (bug reports here and here). So, I switched to PHP 7.1 FPM, which solved the problem (I'm planning on switching to PHP 7.3 mod_php later).

The speed of my webpages is now a little faster as with PHP 5.6 mod_php, which is as expected.