# Practical comparisons on PHP7 - Thread: https://externals.io/message/89729 - Original archive: https://news-web.php.net/php.internals/89729 - Started by Lester Caine on 2015-12-08T00:28:39+00:00 - Messages: 17 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #89729 — Lester Caine — 2015-12-08T00:28:39+00:00 URL: https://externals.io/message/89729#89729 OK now have a working nginx server with both the current production setup and PHP7 php-fpm both running the same code base ... Just a few __construct switches from their named constructor ( still don't see why we need to kill the named version MUCH tidier seeing the name of the parent class ) and everything is running clean. Only problem ... PHP7 is around 10% slower ... and given that half the time is taken in database lookup, the code performance is potentially worse. So what am I missing? lsces.org.uk php7.lsces.org.uk (On a slow local network link so my take a while to display remotely) /phpinfo.php gives the setup of each php-fpm instance. Have a letsencrypt based https on the original version but it's not working with the php7. sub domain :( One thing I do need to put on the bug list is fixing compile warnings in the php_firebird and interbase extensions, but they do seem to be working OK. Pass all tests. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #89730 — Rasmus Lerdorf — 2015-12-08T02:17:25+00:00 URL: https://externals.io/message/89729#89730 · In reply to: #89729 > > PHP7 is around 10% slower ... and given that half the time is taken > in database lookup, the code performance is potentially worse. So what > am I missing? Then you have a config problem. The first and obvious thing to check is your opcache setup. Is it working? `phpinfo()` will show you some cache stats. If opcache is working, what does your opcache config look like? Did you compile with huge page support? If so, did you actually allocate some huge pages for it? If those things look ok, an strace of a request might show something. Another really handy tool is perf. You can attach php-cgi to the socket nginx is sending requests to and perf record/perf report it. That will give you a nice report showing where it is spending it's time. With a properly configured setup there is absolutely no way for PHP 7 to be slower than PHP 5. -Rasmus --- ## #89731 — Rasmus Lerdorf — 2015-12-08T02:23:38+00:00 URL: https://externals.io/message/89729#89731 · In reply to: #89730 > > > […] > > Then you have a config problem. The first and obvious thing to check is your opcache setup. Is it working? `phpinfo()` will show you some cache stats. If opcache is working, what does your opcache config look like? Did you compile with huge page support? If so, did you actually allocate some huge pages for it? Ah, I just checked. You have no opcache at all in your PHP 7 setup. And you have eaccelerator configured for PHP 5. So an opcode cached PHP 5 is only 10% faster than a completely unaccelerated PHP 7. That's pretty damn impressive! -Rasmus --- ## #89745 — Lester Caine — 2015-12-08T12:32:29+00:00 URL: https://externals.io/message/89729#89745 · In reply to: #89731 > Ah, I just checked. You have no opcache at all in your PHP 7 setup. And you have eaccelerator configured for PHP 5. So an opcode cached PHP 5 is only 10% faster than a completely unaccelerated PHP 7. That's pretty damn impressive! Gallery page with heavier load Execute Memory Queries Database PHP5.4 eaccelerator off ... 0.60s 10.14Mb 153 0.39s eaccelerator on ... 0.49s 3.57Mb 153 0.39s PHP5.6 TODO PHP7 opcache off ... 0.50s 7.00Mb 153 0.30s opcache on ... 0.40s 2.00Mb 153 0.30s I'm still taking the 'twice as fast' claim with a pinch of salt, and I'm only seeing opcache is performing as well as eaccelorator, so the idea that PHP7 is an 'essential upgrade to improve performance' may have relevance with some applications, but for the average user simply upgrading the computer may have a better result? I'm still interested in the idea of improving async operations such as not having to wait for all database results until essential, and I'm a little curious why the database service time is so much shorter between 5 and 7 THAT is the major gain between versions. But I need to check if 'Execute' was the total or excludes the database element. I had thought it was the total as the 'Server Stats' also includes the percentage of time handing database queries. Since exactly the same database service is providing both they should be identical so something else is affecting that figure. Bottom line is that given the real world loading on my sites, the differences are probably in the noise of network transit times so not impressive at all :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #89748 — Ferenc Kovacs — 2015-12-08T14:27:23+00:00 URL: https://externals.io/message/89729#89748 · In reply to: #89745 > > > […] > you have eaccelerator configured for PHP 5. So an opcode cached PHP 5 is > only 10% faster than a completely unaccelerated PHP 7. That's pretty damn > impressive! > > Gallery page with heavier load > Execute Memory Queries Database > PHP5.4 > eaccelerator off ... 0.60s 10.14Mb 153 0.39s > eaccelerator on ... 0.49s 3.57Mb 153 0.39s > PHP5.6 > TODO > PHP7 > opcache off ... 0.50s 7.00Mb 153 0.30s > opcache on ... 0.40s 2.00Mb 153 0.30s > > I'm still taking the 'twice as fast' claim with a pinch of salt, and I'm > only seeing opcache is performing as well as eaccelorator, so the idea > that PHP7 is an 'essential upgrade to improve performance' may have > relevance with some applications, but for the average user simply > upgrading the computer may have a better result? > > I'm still interested in the idea of improving async operations such as > not having to wait for all database results until essential, and I'm a > little curious why the database service time is so much shorter between > 5 and 7 THAT is the major gain between versions. But I need to check if > 'Execute' was the total or excludes the database element. I had thought > it was the total as the 'Server Stats' also includes the percentage of > time handing database queries. Since exactly the same database service > is providing both they should be identical so something else is > affecting that figure. > > Bottom line is that given the real world loading on my sites, the > differences are probably in the noise of network transit times so not > impressive at all :( > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk > > -- > > > > I think you should simply get better instrumentation/benchmarking methods before rushing your conclusions. Usually it is also helps if others can reproduce your results either to verify your claims or spot the mistakes causing the bogus results. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #89752 — David Zuelke — 2015-12-08T15:02:19+00:00 URL: https://externals.io/message/89729#89752 · In reply to: #89745 > Bottom line is that given the real world loading on my sites, the > differences are probably in the noise of network transit times so not > impressive at all :( ... or you have a bunch of very slow queries in there that are eating up the majority of request time regardless of PHP version. Sorry, Lester, but what you're posting here indicates that the experiment you're running is not very well designed and contains a lot of unknown variances between your setups. Please fix that and run some properly set up to get genuinely comparable results. P.S. Why do you even still run eaccelerator in the year 2015!? --- ## #89769 — Jefferson Gonzalez — 2015-12-09T03:48:07+00:00 URL: https://externals.io/message/89729#89769 · In reply to: #89745 > > > […] > > Gallery page with heavier load > Execute Memory Queries Database > PHP5.4 > eaccelerator off ... 0.60s 10.14Mb 153 0.39s > eaccelerator on ... 0.49s 3.57Mb 153 0.39s > PHP5.6 > TODO > PHP7 > opcache off ... 0.50s 7.00Mb 153 0.30s > opcache on ... 0.40s 2.00Mb 153 0.30s > > I'm still taking the 'twice as fast' claim with a pinch of salt, and I'm > only seeing opcache is performing as well as eaccelorator, so the idea > that PHP7 is an 'essential upgrade to improve performance' may have > relevance with some applications, but for the average user simply > upgrading the computer may have a better result? > > I'm still interested in the idea of improving async operations such as > not having to wait for all database results until essential, and I'm a > little curious why the database service time is so much shorter between > 5 and 7 THAT is the major gain between versions. But I need to check if > 'Execute' was the total or excludes the database element. I had thought > it was the total as the 'Server Stats' also includes the percentage of > time handing database queries. Since exactly the same database service > is providing both they should be identical so something else is > affecting that figure. > > Bottom line is that given the real world loading on my sites, the > differences are probably in the noise of network transit times so not > impressive at all :( > Well I did my own benchmark with my custom made CMS on AMD bulldozer: PHP 5.6 with opcache takes as a median 60ms to render a page. PHP 7.0 without opcache takes as a median 30ms to render a page. PHP 7.0 with opcache takes 5ms as a median to render a page. So as somebody already said, maybe your code or setup is really busted. PHP 7.0 without opcache can be as twice as fast than PHP 5.6 with opcache, while PHP 7.0 with opcache maps the floor with PHP 5.6. --- ## #89772 — Benjamin Eberlei — 2015-12-09T16:19:35+00:00 URL: https://externals.io/message/89729#89772 · In reply to: #89769 > > > > […] > Well I did my own benchmark with my custom made CMS on AMD bulldozer: > > PHP 5.6 with opcache takes as a median 60ms to render a page. > > PHP 7.0 without opcache takes as a median 30ms to render a page. > > PHP 7.0 with opcache takes 5ms as a median to render a page. > > So as somebody already said, maybe your code or setup is really busted. > PHP 7.0 without opcache can be as twice as fast than PHP 5.6 with opcache, > while PHP 7.0 with opcache maps the floor with PHP 5.6. please take a look at the 90%, 95% and 99% percentiles as well. Medians and Averages are really bad for perf comparisons, especially in isolation. --- ## #89773 — Rowan Collins — 2015-12-09T16:24:12+00:00 URL: https://externals.io/message/89729#89773 · In reply to: #89769 Jefferson Gonzalez wrote on 09/12/2015 03:48: > So as somebody already said, maybe your code or setup is really busted. Really busted, or spending all its time in a type of operation that ZE3 can't particularly optimize... --- ## #89776 — Lester Caine — 2015-12-09T19:02:34+00:00 URL: https://externals.io/message/89729#89776 · In reply to: #89773 > > […] > > Really busted, or spending all its time in a type of operation that ZE3 > can't particularly optimize... But I'd like to understand why what is fairly simple PHP code is apparently not working as some of you seem to expect. Much of the original code goes back to PHP4 days and has been optimised and updated over the years and re-factored a couple of times. It's doing the jobs required and giving response times that clients are happy with in the sub second on intranets. The only PHP7 fixes so far is a few __construct changes from the original named constructor ... the rest of the code is already e_strict clean. So where should I be looking to work out why PHP7 seems little better than PHP5. This code is ADOdb and Smarty based with templates which have developed over 10+ years and we can switch on page caching for the static material, but many sites are running with dynamic data such as calling clients from queues and displaying dynamic information pages. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #89777 — David Zuelke — 2015-12-09T19:21:53+00:00 URL: https://externals.io/message/89729#89777 · In reply to: #89776 Then do a trace with xhprof/xdebug/blackfire and see where the time is spent. How should we magically know the answers? > > > > > […] > > But I'd like to understand why what is fairly simple PHP code is > apparently not working as some of you seem to expect. Much of the > original code goes back to PHP4 days and has been optimised and updated > over the years and re-factored a couple of times. It's doing the jobs > required and giving response times that clients are happy with in the > sub second on intranets. The only PHP7 fixes so far is a few __construct > changes from the original named constructor ... the rest of the code is > already e_strict clean. > > So where should I be looking to work out why PHP7 seems little better > than PHP5. This code is ADOdb and Smarty based with templates which have > developed over 10+ years and we can switch on page caching for the > static material, but many sites are running with dynamic data such as > calling clients from queues and displaying dynamic information pages. > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #89778 — Mike Willbanks — 2015-12-09T19:46:22+00:00 URL: https://externals.io/message/89729#89778 · In reply to: #89776 Lester, > > > […] > > But I'd like to understand why what is fairly simple PHP code is > apparently not working as some of you seem to expect. Much of the > original code goes back to PHP4 days and has been optimised and updated > over the years and re-factored a couple of times. It's doing the jobs > required and giving response times that clients are happy with in the > sub second on intranets. The only PHP7 fixes so far is a few __construct > changes from the original named constructor ... the rest of the code is > already e_strict clean. > This states nothing of how the code was architected and therefore cannot provide any realistic baseline as others have noted. In addition to this, your comparing apples to oranges. The speed increases in PHP itself do not always translate 100% to application performance. Without looking at execution performance on a function level and realizing what is actually taking the time this is a worthless conversation to be frank. > > So where should I be looking to work out why PHP7 seems little better > than PHP5. This code is ADOdb and Smarty based with templates which have > developed over 10+ years and we can switch on page caching for the > static material, but many sites are running with dynamic data such as > calling clients from queues and displaying dynamic information pages. > ADOdb and Smarty have not had MAJOR releases in several years. Smarty 3.1 was in 2011 while Smarty 3 was in 2010. ADOdb's last major release was in 2007. These are your implementation details and things that YOU are leveraging, these are not necessarily a standardized approach. Page caching changes things dramatically as now you're simply requiring things. If your spending time in query execution then thats why there is no significant gain. Overall, profile your code, look at the cachegrind output in the case of xdebug and then look at instruction time. Then you will have an idea where the time is being spent and can actually have a concrete discussion around performance and what is actually taking the processing time. Anything short of that, including this reply is a waste of time for everyone on this list. > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #89785 — bjorn.x.larsson@telia.com — 2015-12-10T11:02:34+00:00 URL: https://externals.io/message/89729#89785 · In reply to: #89778 Den 2015-12-09 kl. 20:46, skrev Mike Willbanks: > Lester, > > > > > […] > This states nothing of how the code was architected and therefore cannot > provide any realistic baseline as others have noted. In addition to this, > your comparing apples to oranges. The speed increases in PHP itself do not > always translate 100% to application performance. Without looking at > execution performance on a function level and realizing what is actually > taking the time this is a worthless conversation to be frank. > > > > […] > ADOdb and Smarty have not had MAJOR releases in several years. Smarty 3.1 > was in 2011 while Smarty 3 was in 2010. ADOdb's last major release was in > 2007. These are your implementation details and things that YOU are > leveraging, these are not necessarily a standardized approach. Page > caching changes things dramatically as now you're simply requiring things. > If your spending time in query execution then thats why there is no > significant gain. Just noticed that Smarty team is working on a 3.1.28 relase that plans to be PHP 7 compliant, see: https://github.com/smarty-php/smarty Regards //Björn --- ## #89787 — Lester Caine — 2015-12-10T11:16:11+00:00 URL: https://externals.io/message/89729#89787 · In reply to: #89785 > Just noticed that Smarty team is working on a 3.1.28 relase that plans > to be PHP 7 compliant, see: https://github.com/smarty-php/smarty The version I'm running is not giving any errors, similarly ADOdb. Both were brought up to be clean on PHP5.4 and that seems to be the case with most BC problems. BUT should either of these packages need any 'major upgrade' to take advantage of a faster PHP7? They are e_strict compliant and well structured so why would they not perform twice as fast on PHP7? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #89788 — David Zuelke — 2015-12-10T12:43:18+00:00 URL: https://externals.io/message/89729#89788 · In reply to: #89787 Lester, we are software developers. not fortune tellers. Stop speculating. Gather data. Profile your stuff and look where the bottlenecks are. > > > > > […] > > The version I'm running is not giving any errors, similarly ADOdb. Both > were brought up to be clean on PHP5.4 and that seems to be the case with > most BC problems. BUT should either of these packages need any 'major > upgrade' to take advantage of a faster PHP7? They are e_strict compliant > and well structured so why would they not perform twice as fast on PHP7? > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #89789 — bjorn.x.larsson@telia.com — 2015-12-10T12:54:40+00:00 URL: https://externals.io/message/89729#89789 · In reply to: #89787 Den 2015-12-10 kl. 12:16, skrev Lester Caine: > > > […] > The version I'm running is not giving any errors, similarly ADOdb. Both > were brought up to be clean on PHP5.4 and that seems to be the case with > most BC problems. BUT should either of these packages need any 'major > upgrade' to take advantage of a faster PHP7? They are e_strict compliant > and well structured so why would they not perform twice as fast on PHP7? > Well, in the changelog dated 28.07.2015 they mention a PHP 7 compliant update. I don't know if it's a must to run Smarty 3.1.28-dev in order use PHP 7. Anyway, I plan to test Smarty with PHP 7 later in january next year. Regards //Björn --- ## #89796 — Ronald Chmara — 2015-12-10T17:08:24+00:00 URL: https://externals.io/message/89729#89796 · In reply to: #89787 > > > […] > The version I'm running is not giving any errors, similarly ADOdb. Both > were brought up to be clean on PHP5.4 and that seems to be the case with > most BC problems. BUT should either of these packages need any 'major > upgrade' to take advantage of a faster PHP7? Few software stacks should need any major changes to use PHP7. They are e_strict compliant > and well structured so why would they not perform twice as fast on PHP7? If a portion of a stack is poorly architected, poorly written, or poorly implemented, the gains in moving to PHP 7 may be negligible. PHP7 does not double the speed of accessing or updating databases, so if a page is bogged down by an large amount of DB queries, PHP7 will not fix that. PHP7 does not double the speed of filesystem reads and file writes, so if a page has significant amounts of local filesystem access (say, using class/file auto-loaders, or messes around with a whole bunch of template files, data files, whatever) PHP7 will not fix that. PHP7 does not double the speed of network interactions, so if a page has significant amounts of network access (say, pulling data from other URL's, ) PHP7 will not fix that. PHP7 does not double the execution speeds of non PHP library calls, so for example, (in addition to db access libraries) image manipulation libraries, PDF builders, (etc.) will not see increased execution speeds, as they are outside of PHP7. ...Those are just some of the low hanging fruit I've run into professionaly that have showed big gains in addressing. There are lots of possible reasons why PHP7 will show dramatic improvements for some, and little improvement for others. The "PHP7 may double speeds" holds true for certain kinds of PHP code, and usage, but if a page is currently bogged down with crap code, or external calls to things outside of PHP, the overall gains in changing to PHP7 may not be dramatic. -Ronabop