Here are three tools that saved my butt during this last week. The least I can do is heap a little praise on them.
I've written about mysqlreport before. And everything I've said about it still stands: it's the most efficient tool I've found to gather and present performance data on a MySQL database. Unfortunately, the project behind mysqlreport has been retired. This means, among other things, that the 1-line install I've used previously for setting up mysqlreport no longer works.
to grab the latest (and apparently final) version mysqlreport. From there, you can start debugging away.
WordPress SQL Executioner
Like mysqlreport, I've blogged about this plugin before (nearly 4 years ago). Last night I was working on a GoDaddy managed WordPress blog and found that I needed to tweak a bunch of posts. I had imported the posts using the very slick WP All Import plugin, but I needed to take the posts from being drafts to being scheduled, and I needed to set their post dates. It was far too painful to consider manually updating each post. Normally I'd craft a MySQL or PHP solution by manually connecting up to the database and just "fixing" these posts. Unfortunately, because this is a managed environment, I don't have access to the underlying database.
Fortunately, GoDaddy allowed me to install WP SQL Executioner, in all it's ridiculously unsafe glory. I then kicked off an SQL statement like so:
UPDATE $posts SET post_date = ..., post_status = 'future' WHERE id IN (...)
And all the relevant posts became scheduled. When I realized the blog was setup to be in the UTC timezone and I needed to update the posts to be in EST, I simply ran the following:
UPDATE $posts SET post_date_gmt = post_date + INTERVAL 4 HOUR WHERE id in (...)
To make sure WordPress fully absorbed these behind the scene changes, I went into the wp-admin UI and bulk edited all the posts. I simply set a category on them that they all already had. The result was properly scheduled posts.
Note to self: I've got to find (or write) a similar plugin that runs arbitrary PHP code. Yeah, how could that cause problems?
While I've never blogged directly about tcpdump, I've made passing mention of it. It's one of those low level, super powerful, tools for debugging all things network related. The problem I have with it is that it tends to give me *too* much information. Enter Chaosreader, a tool I learned about from this post. Chaosreader slurps in a raw tcpdump file and delivers to you a neatly organized breakdown of the high and low level traffic.
I recently used it to understand how the Flash Media Server's Admin Console functions. Because the Admin Console is written in Flash, a number of my normal techniques for debugging weren't possible (read: firebug and fiddler). Tcpdump, on the other hand, runs on the server and could care less about where the connections are coming in from. So I generated a massive tcpdump file, fed it to Chaosreader and worked out from there which FMS Admin API calls were being invoked. Turns out getUserStats returns the stats for individual client connections, not FMS users, like I assumed the name implied.
Bottom line, for seeing both the forest and the trees, at least when it comes to TCP network traffic, you need Chaosreader.