There are tons of optimization/performance logging tools out there. Most frameworks (cake, CI) have their own, and I'm a big fan of pQp, for no other reason that it's clean and nice to look at.
For the most part, though, I've always relied on my own practices. Spitting out the number of db queries (inserts, selects, explains, etc.), Memcached hits, APC hits, global variables hits, memory usage, etc. etc. is something I do often and monitor non-stop during development.
Most of the time in doing so, I'll spit out a custom table that has these stats arranged. Nothing fancy, but very functional. An issue I ran into was how to monitor/gauge ajax performance. I couldn't just spit it out at the end of the buffer since the ajax was normally JSON encoded.
Something I came up with (I'm sure others have done this, but haven't found it) is to, globally, in my development/local environment, attach all these metrics to the response headers instead. Using php this is fairly easy (I believe just using the header function). Then I can do the same with ajax without affecting the view that is rendered/compiled.
The problem obviously comes with watching this data. I do this non-stop. Every page load almost, I'm checking those stats to see if some code I wrote dramatically affected the load time, db hits, or whatever else I'm measuring at the moment. I don't want to have to open up Firebug or some http header interceptor every time I want to take a look.
This is where a quick MooTools class comes in. In a nutshell, when the page loads and whenever an ajax call is performed, I create a new PerformanceMonitor object which checks the header of the html page or ajax call and then spits that out somewhere on the page. I can define a callback function so that I can handle that data however I'd like, but what this now does is offer a universal way to monitor a request regardless of how it was retrieved. This should work with JSONP as well, and realistically, loading any asset at all can have this PerformanceMonitor plugged in (after the asset is loaded) to check how the server handled it.
I'll update this post when I've made the MooTools class optimized for general usage, but for now, hopefully this approach gives someone an idea to performance monitoring for a more complicated web app that doesn't rely on pure synchronous requests.