0

As it happens often to coders, I had to take over someone else's code for this company, the server runs on Amazon Cloud (i2.xlarge) running ubuntu-saucy-13.10-amd64-server. (the guy left)

The server has 700GB SSD and 30GB RAM but my problem is the previous developer was lousy at writing SQL statements as well as the PHP scripts I see have terribly long and unecessary loops.

I thought of looking at PostgreSQL logs but then I still need to match queries to php pages (long and painful process).

Is there a way for me to tell which PHP page is doing the "most damage" to the server in terms of resource hog so I can start replacing the worst ones first?

Any help is greatly appreciated, I've been at this for awhile.

Improve this question
3
  • stackoverflow.com/questions/55720/… almost identical question on SO, thats probably worth reading.
    – Journeyman Geek
    Jan 24, 2014 at 3:06
  • I don't remember it being safe to add xdebug to production server, it's the only one that get's the load I need to test with. unless i am wrong and it's 100% safe to use this on Prod.
    – Drace
    Jan 24, 2014 at 3:08
  • I've seen servers with xdebug left on for months with no noticeable impact. That's not to say it's a good idea, but if you have to do it...
    – Michael Hampton
    Jan 24, 2014 at 3:31

2 Answers 2

Reset to default
1

First things first:

  • Enable MySQL slow log and inspect it - this will give you the most heavy queries. Try to match them to the pages
  • do static analysis to find some obvious errors
  • implement some logging of page performance (e.g. microtime timestamping etc)
  • start a general and medium paced code review starting with the most used pages (webserver logs are a good place to see frequencies)
  • enable request time logging in your webserver so you can track page performance.

And obviously using a debugger is a nice touch.

More to the point setup a copy of the production for tests so you can play around it. If on the copy these problems are not observed, then the issue lies with DB configuration - memory usage, indexes, querry cache etc.

Improve this answer
1

If you're running PHP-FPM, you can enable the slow log. Set request_slowlog_timeout to the number of seconds you consider "slow" and make sure that the value of slowlog is pointing to somewhere you can write to.

If you have (or can install) (XHProf)[http://pecl.php.net/package/xhprof] then you can get a wealth of profiling information from it. It's a very lightweight profiler and I've run it in production on a very busy site with no ill effects.

If you aren't running PHP-FPM and you can't (or would prefer not to) install XHProf and if you know for sure that DB queries are at fault then my approach would be to start with the PostgreSQL slow log. If you can find the slowest queries then odds are a quick grep will find which pages they belong to. It's not ideal, but it's better than nothing.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .