Jonathan Brinley and I had a fun little adventure today. We set out to fix our app and learned that really we just needed to fix our metrics.
We launched a fantastic WordPress multisite project for Café bon Appétit on Friday. Seeing as how this is fundamentally a migration from a previously existing site, we set up New Relic a week ahead of time so that we could monitor how the site performance changes. However, after our deployment, it became apparent that the new site was not performing very well at all.
As you can see in the graph below, there is a rather expensive overhead (green) for what appears to be “Web external”. What’s more is our “Apdex score“, a number that is designed to rate performance, was looking really bad (gotta keep it in the green or blue).
Fortunately, New Relic allows us to simply click on the graphs to learn more. As we dug into it, we quickly learned that our cronjob was the culprit. At first we pondered if there’s anything we should do to improve performance. But after a little research and some philosophy, we concluded that really what we need to do is separate the New Relic tracking for requests that are made by the public from those made by the server itself, and even from requests made by logged in WordPress users who are creating content.
The thinking is that we’re caching the crap out of this sucker for front end users and I want to know that the site is blazing fast for those users. Secondly, I want to know how well the logged in load time is and if there are any problems effecting admin users. And lastly, and leastly, I’d like to have some reporting for server initiated processes.
The solution turns out to be rather simple. Jonathan put together this wonderfully elegant plugin that we dropped in the mu-plugins folder. Immediately after deploying that, the reporting on site performance snapped into place, blood pressure dropped, and we lived happily ever after.