Results 1 to 13 of 13
  1. #1

    PHP 5.4 Slower, MySQL 5.7 Slower

    Old vs New
    Replaced an E3v1 based server with a similarly clocked E3v3 Haswell based server. I was expecting around a 15% increase in speed and this does seem to be the case.

    Installing the O/S, compiling, running test benchmarks showed that the change from a V1 to V3 CPU did indeed speed things up by 10-20%.

    Then I installed the website: Apache, MySQL, PHP, the static pages, images, php scripts ...

    Newer = Slower
    I was disappointed to note that the new server was now serving pages at the same speed as the old server! A particular report on the old server would take 11.7 seconds to generate. On the new server it was taking ... 11.7

    How could this be? The backend stuff was faster. The php scripts and database were the same. Then I realised two differences: The new server was running the latest PHP 5.4 and MySQL 5.7 (development release), whilst the old server was running 5.3 and 5.6.

    I installed the later versions because I read things like "PHP 5.4 is X% faster than PHP 5.3", "MySQL 5.7 is Y% faster than 5.6". I read the articles, saw the charts, and I believed it.

    Well guess what. It's BS. Well certainly for my setup.

    Rollback = Result
    I downgraded to PHP 5.3 and it shaved a second off the report. I then downgraded MySQL to 5.6 and that shaved another second off the report. The report that took 11.5 seconds on the old server is now generated in under 10 on the new server.

    Maybe it is my programming style, maybe it is my over optimizing of a solid platform, but there is no way that newer versions of PHP and MySQL are faster than the previous versions!

    What To Do?
    5.3 is EOL now, and is only receiving security upgrade for another 6 months or so so it will have to be replaced sometime. I tried 5.5 but that was only very slightly faster than 5.4 (but still slower than 5.3). I think I will hold off until 5.7, or 6!

    MySQL seems to be bloating with new features I don't need. There is also the issue of focusing on InnoDB (I prefer the speed of MyISAM and MEMORY tables). If the GA releases of 5.7 are still slower than 5.6 then I guess I could try Maria or Percona.

  2. #2
    Join Date
    Jan 2013
    Posts
    75
    As I was reading your post I chuckled to myself, thinking back years ago to when I was attending a computer science lab class where the person sitting next to me was becoming upset because, in his words, “There is something wrong with the compiler” since his code did not work. I’m not saying I see anything in your post to indicate a level of anger or anything of that nature, it’s just that as programmers we have to accept reality, that there are rules that come into play and that ultimately PHP and MySQL are nothing but tools. I won’t go into detail about whether I think PHP 5.4/5.5 are faster and the same applies for MySQL. There might very well be something with PHP/MySQL that are causing your reports to be generated slower on the newer versions in comparison to older releases but that is irrelevant.

    You have spent a great deal of time it appears trying to find the best version of PHP and MySQL but you are going about things entirely wrong. It appears you have complete control over your servers infrastructure which is a great thing, so here is my suggestion. You upgrade to PHP 5.5, and the latest stable MySQL (5.6.14). You then begin to ask, not why is there something wrong with PHP or MySQL, but rather what is wrong with your scripts.

    You can either move forward or backward, but at some point you will have to investigate why your scripts are taking longer to generate their reports on modern versions of PHP/MySQL. It would be best to determine that now and make improvements to your code. It’s always a pain to debug things, but you will really need to break down your code to determine how much time each segment of your code is taking to generate.

    I don’t mean to be harsh or anything, but in your post you didn't mention anything about trying to troubleshoot the source of your slow report generation time and what that ultimately suggests is, that your focus needs to be spent with your code, rather than your PHP or MySQL version. At the end of the day you are responsible for how long your reports take to generate, so you can blame others, or you can work on your software, until you have devised a solution. That is what software development is all about.

    At this point in time it does not seem clear as to whether you even know if your issue is related to PHP or to inefficient MySQL queries, so I would encourage you to start your debugging and from there on, I’m sure you will find the reason for the delay in report generation.

  3. #3
    I get your point. But there is a clear issue here: Both PHP and MySQL claimed that their later versions are X% faster. I am not seeing that, in fact I am seeing a decrease in performance.

    The code is the same, the database is the same. The only difference is the hardware and the versions. The hardware is faster and yet when PHP and MySQL are run they are slower on the newer version.

    It could be that my style of coding is wrong and not compatible with the later versions.

    If you would like to post a simple benchmark script, or link to such a script then I will test it again and thus isolate myself from the test.

  4. #4
    Join Date
    Jan 2013
    Posts
    75
    Quote Originally Posted by Larry David View Post
    I get your point. But there is a clear issue here: Both PHP and MySQL claimed that their later versions are X% faster. I am not seeing that, in fact I am seeing a decrease in performance.
    Sounds like a coding problem and you should take my advice and investigate it. You still do not seem to know if the issue is related to PHP or MySQL. In my view I see PHP and MySQL as a platform, if there are issues on that platform, you need to find out why they exist. It's not good enough to just to claim that you are seeing a decrease in performance, you need to figure out why that is, otherwise no one can help you.

    Quote Originally Posted by Larry David View Post
    It could be that my style of coding is wrong and not compatible with the later versions.
    If at this point you have yet to break that ~10 to 11.7 second number into smaller segments and understand fully, why you are getting that number (Time per query, time per executing specific functions or some similar method), you need to get it done or hire someone who can, since that is what will fix your problem on the newer versions of the software, along with perhaps helping you reduce 11.7 to something like 5.7 seconds.

    Once you have added whatever debug statements that are needed with your code, if for some reason you really want to test older software versions for some reason that is still unclear to me, at least you will know which functions/queries are responsible for the changes in response time and then you can take things from there.

    Quote Originally Posted by Larry David View Post
    If you would like to post a simple benchmark script, or link to such a script then I will test it again and thus isolate myself from the test.
    The problem here is you are still suck on the idea of your code not being the problem, but rather it's PHP and MySQL. So what if it was? Even if it was PHP/MySQL, that won't matter in the slightest, if something was changed, you will need to change with the times. It's not so simple as running a test script since a simple test script is not going to take into account a wide variety of factors that actually lead to higher response times, since the real key is understanding what causes delays in response time in the first place.

    I understand an answer such as that may not be understood in your case so I've done some research and found some people who claim to have had better response time under PHP 5.4.x than the previous versions.

    PHP Benchmarks showing PHP 5.4 improved response time:
    http://architects.dzone.com/articles/php-54-benchmarks
    http://www.lornajane.net/posts/2012/php-5-4-benchmarks
    http://www.eschrade.com/page/magento...-4-and-5-5rc3/
    http://ckon.wordpress.com/2012/02/07...ster-than-5-3/

    What you can see from the above, due to various individuals testing different software applications is that actual core changes in PHP 5.4 have led to a more efficient method of interpretation. The above links show you that Drupal, Zend Framework, Wordpress, Xoops, Magento and others all perform better on modern versions of PHP. It's interesting to note here that everyone seems to experience better response times on PHP 5.4+ but you, and that should tell you something.

    If you are looking for a test script see:
    http://www.lornajane.net/posts/2012/...ast-as-php-5-3

    Looking for test results? I compiled PHP 5.3, 5.4 and 5.5 on a test VM on a box with no traffic and here are my results.

    PHP 5.3.27
    # php a.php
    time taken: 1.9372549057007
    # php a.php
    time taken: 1.9023728370667
    # php a.php
    time taken: 1.9203498363495

    PHP 5.4.21
    # php a.php
    time taken: 0.9462149143219
    # php a.php
    time taken: 0.96440505981445
    # php a.php
    time taken: 0.95430588722229

    PHP 5.5.5
    # php a.php
    time taken: 0.89802193641663
    # php a.php
    time taken: 0.90749096870422
    # php a.php
    time taken: 0.92630004882812

    Just to note that these time discrepancies are the result of object instantiation only. It serves as a great example of how much work the PHP team have really invested into their product. I actually went further and tested on some of my own projects and saw similar results.

    Of course the links I've provided do not account for changes within MySQL, but you're a smart guy, I assume you can do your own research. There are other test scripts out there for PHP, and will test things more appropriately but I'll let you find/devise your own.

    So what to do now?
    1. You can continue to lay the blame on something that PHP or MySQL have done in newer versions of their software as an excuse for not modernizing your software.
    2. Add debug statements showing response time to your code, find the bottleneck and work to improvise a solution.
    3. Run old outdated software.

    Choose wisely.
    Last edited by SocketMain; 11-11-2013 at 06:41 PM.

  5. #5
    Thanks for the links. It was the lornajane test, which initially inspired me to install 5.4 on the new box. Running that test, and the others, does indeed show improvement with 5.4 over 5.3.

    So that proves there is a 'code compapability problem' (but not necassirly a coding problem itself)

    PHPBB
    I ran tests on phpbb3. In all instances page loads (forum view, page view, forum search) are slower with 5.4 than 5.3. phpbb is not my code so whatever phpbb is doing, it does not work well with the later version of PHP either.


    Something Else?
    If there is an issue with software written by a team of developers, which results in slower usage rather than faster usage on later versions of PHP then there could be something under the hood that is the problem.

    CFLAGS
    php configure string
    Apache 2.4 / configuration
    Modsecurity
    Site Membership program
    The way Centos 6.4 was installed / built / optmized.
    Versions of compiler software
    IPTables

    This could take some time isolate.

  6. #6
    Join Date
    Jul 2002
    Location
    London, United Kingdom
    Posts
    4,455
    We've seen several client-sites that are heavy PHP/MySQL get slower by noticable amounts on recent mysql versions.

    Some of that we could help counteract by looking at their code/queries and suggesting doing more in the query than pulling all the records and doing it in PHP (several times!), but having tested those mods back on a snapshot of their VPS which still had 5.0.95 it's still a 15%+ performance decrease using the latest version for them.
    Rob Golding Astutium Ltd - UK based ICANN Accredited Domain Registrar - proud to accept BitCoins
    Buying Web Hosts and Domain Registrars Today @ hostacquisitions.co.uk
    UK Web Hosting | UK VPS | UK Dedicated Servers | ADSL/FTTC | Backup/DR | Cloud
    UK Colocation | Reseller Accounts | IPv6 Transit | Secondary MX | DNS | WHMCS Modules

  7. #7
    Fascinating! Isolating each part in turn (listed above) I find that the configure script is the problem.

    As a test I ran a plain, vanilla

    ./configure

    rather than the standard install script I use. Doing so reduced the report run time down to less than 9 seconds for all three versions.

    Next step is to disect the configure script to see which enable / disable / with / without is causing the problem.

    Code:
    #
    # conf_php.sh
    # This install file causes some php scripts to run slower in versions 5.4/5.5
    #
    
    CXX=gcc
    CXXFLAGS="-O3"
    CFLAGS="-O3"
    
    ./configure \
    --prefix=/usr \
    --with-apxs2="/usr/local/apache2/bin/apxs" \
    --with-config-file-path="/etc/" \
    --libdir=/usr/lib64 \
    --with-libdir=lib64 \
    --with-mysql \
    --with-mysqli \
    --with-curl=/usr/lib64 \
    --with-zlib \
    --with-gd \
    --without-iconv \
    --without-sqlite \
    --without-sqlite3 \
    --enable-libxml \
    --enable-bcmath \
    --enable-session \
    --enable-soap \
    --enable-inline-optimization \
    --disable-debug \
    --disable-ipv6 \
    --disable-phar \
    --disable-pdo \
    
    make -j9
    make install
    strip /usr/bin/php
    strip /usr/bin/php-cgi

  8. #8
    Nope. That was a red herring It doesn't look as if any of those configure options is the problem.

    All I know is that a recent change (possibly a Yum update) has caused all versions to now run the report in around 8.8 seconds. Neither 5.4 or 5.5 are faster than 5.3 but at least they are now not 1 to 2 seconds slower like previously.

  9. #9
    Join Date
    Mar 2013
    Posts
    1,328
    I am disappointed with MySQL 5.6 too.

    I tried to switch from 5.5 and went back to 5.5 immediately as soon as I discovered restoring backups was taking longer on 5.6.

    Of course there is more to a database software than INSERT INTO but it was enough reason for me to go back to 5.5.

    Is Oracle screwing up MySQL?

  10. #10
    Try MariaDB. It is a drop in replacement for MySQL thus easy to install. Make sure you have a good backup strategy if you do decide to try it. You can get in a bit of a mess with passwords and such.

    I tried MariaDB 5.5 (which is based on MySQL 5.5) and found it to be about 7% faster than MySQL 5.6

    Then I tried MariaDB 10.0 (based on MySQL 5.6) and found that to be about 10% faster than MySQL 5.6

    That will do for me.

  11. #11
    Quote Originally Posted by Larry David View Post
    Try MariaDB. It is a drop in replacement for MySQL thus easy to install. Make sure you have a good backup strategy if you do decide to try it. You can get in a bit of a mess with passwords and such.

    I tried MariaDB 5.5 (which is based on MySQL 5.5) and found it to be about 7% faster than MySQL 5.6

    Then I tried MariaDB 10.0 (based on MySQL 5.6) and found that to be about 10% faster than MySQL 5.6

    That will do for me.
    How did you run your tests?
    Ive just started moving to MariaDB

  12. #12
    The tests were timings of my own reports.

    I have both servers in DCs now. Obviously there will be a slight difference with latency but the big differences will be the hardware, tuned O/S, versions of httpd, php and MySQL.

    Old Server
    E3-1270V1
    16GB 1333Mhz
    Intel 330SSD 120Gb
    WD HD 250Gb
    Apache 2.2.24
    MySQL 5.6.12
    PHP 5.3.27

    New Server
    E3-1270V3
    32GB 1600Mhz
    Samsung 840 Pro 250Gb
    Velociraptor 250Gb
    Apache 2.4.7
    MariaDB 10.0.6
    PHP 5.5.6

    One of the reports that used to take ~11.5 seconds is now taking ~8.5 seconds on the new server. So not only am I seeeing the natural increase in speed from the change in hardware (15%) but the change to php 5.6, MariaDB are also gaining around 10% each over the older versions.

  13. #13
    Join Date
    Mar 2013
    Posts
    1,328
    Quote Originally Posted by Larry David View Post
    Try MariaDB.
    I am aware of it and it's probably what I will do in the near future.
    Thanks for sharing your test by the way.

Similar Threads

  1. mySQL running 5x slower after optimization?
    By shannont in forum Hosting Security and Technology
    Replies: 4
    Last Post: 08-04-2012, 08:55 PM
  2. photonvps support seems to be slower and slower
    By rryqs888 in forum VPS Hosting
    Replies: 3
    Last Post: 02-03-2012, 10:04 PM
  3. Why mysql mysql_connect() is 1500 times slower than mysql_pconnect()
    By hostingasia in forum Hosting Security and Technology
    Replies: 5
    Last Post: 12-16-2004, 06:07 AM
  4. wht slower slower....
    By pattox in forum Web Hosting Lounge
    Replies: 4
    Last Post: 02-02-2003, 01:07 AM
  5. XP is slower
    By Rewdog in forum Web Hosting Lounge
    Replies: 5
    Last Post: 11-02-2001, 12:21 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •