I am trying to find the best way to monitor which PHP code/functions, MySQL requests and/or plugins are slowing down pages on a site.
I know there are a bunch of different options out there including wordpress plugins and solutions involving firebug (firephp) but what do you guys feel is the best approach?
Personally I feel the ideal solution would be to have some type of code which can be installed by default with every wordpress install. Any debugging/monitoring/reporting would ONLY get executed if you added an optional entry to the end of the URL like ?=debug. For security purposes it would be even better if one would first have to login to the wordpress admin area and create a temp debug key which would create a hashed key and append it to the url (like debugkey=v09098v09aq2ov1a8923) which would only be available for 30 minutes.
But getting back to the actual debug info… I feel using firebug is great in many situations but optionally I feel it would be valuable if one could append something else to any URL which would for example overlay all the functions, hooks or filters used on a specific page along with the execution time for each.
In any case… I figured many of you here must have faced this issues as well and thus I would appreciate whatever solutions you are utilizing to solve your problems.
Please do outline how any specifics for others that might read this describing any specifics on installation and how to use it correctly.
Running a Dedicated Linux Server
There are multiple tools and possibilities, and shure it would be nice to have something quick at hand. I know plugin authors who do offer debug flags so you can analyze what’s going on quite easy.
As for plugins, I have not tested it but looked at some screenshots and it is at least informative: Debug Bar (WordPress Plugin) and the BlackBox Debug Bar (WordPress Plugin).
Another one is a hooktracer that is not that well known: SJ Hook Profiler.
I do heavily recommend xdebug for development and testing systems, it’s a pleasure to have it if you need to profile or debug stuff.
You don’t indicate what your server arrangement is. If you are in a shared hosting environment you have limited options. If it’s your own server, then you can install various profiling tools to get the Big Picture. Look at this thread over on SO for some options.
Also, slowness of the delivered page can be the result of a lot of things, only a few of which are PHP/MySQL related. You can have DNS problems, net congestion at either the client or server end, badly planned pages that have lots of JS loading early rather than late, etc. etc.
To test the fundamental food chain of network connection + server delivery of the basic HTML page, try using the Apache Benchmark program. Careful! You can beat the crap out of a server with this puppy, and your hosting company will not be amused if you do a one-person imitation of a DOS attack on their machine.
Update: OK, a dedicated Linux server gives you important options. In particular, I’ll double-down on xdebug and it’s ability to profile your code’s execution. It’s amazing how quickly a couple of runs under a profiler can shine a bright light on some innocent-looking function that’s chewing up the machine.
If nothing immediately pops out at you, look for routines that seem to be taking more time than they should (whatever that means) and/or seem to be getting called a lot. The later can often be rectified by simply caching the results for certain values. If this is a general problem involving different, high-cost functions being called with different parameters, you can look at memoizing the affected functions. I’ve done this several times in Python, but not in PHP. Here is an article on one person’s approach. There are more posts on this subject out there.
XHProf (open source, part of Facebook stack for their performance monitoring) is pain to setup (at least for Windows person like me), but it’s very thorough and convenient performance profiler tool for PHP.
I wish it had win version for my local test stack. 🙁
I can only recommend the Krumo php class that can be added within 10 sec to any installation and doesn’t depend on any local setup. So even if you’re out and away of your office you got a debug tool with you. Just be sure to load it after any other files and load it with
if ( current_user_can('manage_options') ) krumo::enable(); so no guest or other user runs into your deugging messages if you’re debugging something that’s already live.