Developing P3

WordPress has many great strengths, including its ability to use third party plugins and themes. Sometimes, though, these features can slow down your site. We developed P3 to help customers determine if and how use of various plugins affects their site speed. Here’s how we did it.

For more about our overall approach to hosting performance, see
Achieving Optimum Service.

The Goal: Measure performance and isolate results by plugin

The first step in developing P3 was answering the question, “Is it even possible to group runtime results by plugin?”

We used xdebug to profile WordPress sites to see if we could determine, definitively, how much time was spent running code in each plugin. We discovered that it was possible, but it wasn’t easy. We had to manually trace the plugins through hook functions (do_action, apply_filters).

Prototype and Early Development

We began work on our prototype, building an automated profiler, without using any PHP extensions. For more on code profilers, see Write Your Own Code Profiler in PHP.  Our prototype of P3 was very simple.

The P3 prototype included an easy to understand pie chart that showed the relative runtime of each plugin. This version also included runtime metrics for total, core, and plugins; total function calls (later renamed to “ticks”); and average memory usage.

But, we didn’t stop there. We continued working on P3, adding more data. Here’s P3 just one week after our initial prototype:

This version added two timelines. The first timeline plotted the theme runtime, core runtime, and total plugin runtime. The second timeline plotted the number of database queries. This version also introduced a margin of error measurement (called “drift”) and measured the time spent in the profiler.

A little bit of trivia for you: P3 wasn’t actually named P3 until the very end of the project. We couldn’t agree on a name until it was finished.

We spent the next few months making P3 more compatible, more accurate, more complete, more usable, and writing Help. See Write Your Own Code Profiler in PHP

The next phase of P3 brought a tabbed layout to save space, the callout boxes at the top to make the most important measurements easy to see, and automatic scanning to make P3 easy to use:

Gathering Feedback

We selected a group of Go Daddy’s own Customer Support representatives to act as beta testers and use P3 when handling support calls related to WordPress sites. With feedback about how they were using it, what it was lacking, and when it broke, we continued to refine our code.  Closer to the release date, we showed P3 to a different group of Customer Support representatives to get their feedback. They were very excited to see P3.  Their support experience helped make P3 easier to use.  The ability to send the scan results via email and the tooltips in interface were suggestions we used from this meeting.

Testing

Of course we needed to test P3 thoroughly. Our test cases included different combinations of Web servers, PHP SAPIs, operating systems, opcode cache / optimizer extensions, PHP configurations (e.g., suhosin, open_basedir), and WordPress configurations (e.g. admin SSL, multisite).

We set up a series of test sites with different configurations and an automation suite using Selenium. This way, whenever a new version of WordPress or P3 is ready, we can execute most of our test plan automatically.  On occasion, we need a special test environment to recreate a user reported bug, in which case, we may set up a new virtual machine with our cloud hosting service.

I’d like to thank all of the users who report bugs on the wordpress.org forum and through the P3 support form. We incorporate your feedback into the P3 master test plan.

Finishing up for Release

Just a few finishing touches left to polish up P3 and we were ready to go. We reviewed the code, the edited help content, and made sure that all of the licenses were compliant.

We released P3 in December 2011. Learn more about it in our blog.  After 4 months of development and testing, P3 made its public debut in the wordpress.org repository. The WordPress community picked it up pretty quickly and P3 has received a very positive response. Several blogs, including wpmu.org, have reported a good experience with P3. Even Patrick Meenan (of webpagetest.org) found it!

It’s good to see users adapting P3 in ways we’d never considered.  One user on twitter is working with a plugin author about performance using P3′s metrics:

P3 can help users and developers communicate using objective data which sets the same expectations for everyone. It’s the difference between “my site feels slow sometimes” and “my site loads in 5 seconds and I want it under 4.”

What’s next?

We are updating and testing P3 version 1.3.0 for WordPress 3.4 right now. It reduces memory usage by utilizing an autoloader function and by using hooks more judiciously. We are also working on internationalization so that translators can create their own translations of P3’s interface.

In addition, look for a few bug fixes and a new failsafe feature that detects if there is a fatal error while profiling (for example, out of memory). If an error is detected, on the next page load, profiling is turned off and the error is reported to the user.

What do you want to see in P3?