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
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
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?
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
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
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.30sI'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 - G8HFLContact - 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
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!?
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.30sI'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.
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.30sI'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.
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.
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...
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...
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
Then do a trace with xhprof/xdebug/blackfire and see where the time is spent. How should we magically know the answers?
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...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 - G8HFLContact - 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
Lester,
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...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
- 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 - G8HFLContact - 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
Den 2015-12-09 kl. 20:46, skrev Mike Willbanks:
Lester,
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...
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
- 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
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
Lester, we are software developers. not fortune tellers.
Stop speculating. Gather data. Profile your stuff and look where the bottlenecks are.
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/smartyThe 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 - G8HFLContact - 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
Den 2015-12-10 kl. 12:16, skrev Lester Caine:
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?
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
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?
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