Found three Performance Problems with WP_Piwik

We came across three performance problems in WP_Piwik today while profiling a WordPress with Tideways:

1. We couldn’t put a finger on it, but it seems WP_Piwik::updateTrackingCode() is called in every request inside WP_Piwik\TrackingCode constructor. We debugged a lot but couldn’t find the bug. But every trace we generated always called the updateTrackingCode(). See a callgraph here showing it takes 88ms, which happens in every request.

https://s3-eu-west-1.amazonaws.com/tideways/img/wordpress/WP_Piwik/piwik1.png

I think there is a bug somewhere inside WP_Piwik\TrackingCode constructor leading to the updateTrackingCode() call way too often.

2. PhpFileCache inside WP_Piwik::addJavascriptPixel is very slow

Calling updateTrackingCode every request shouldn’t be a problem in itself, since the resulting API call is usually cached using Doctrine PhpFileCache. However as you can see in the screenshot above, at least on our server that took 19 ms for just six calls. The entire code around it also takes a long time, making up the total of 88ms in the screenshot linked above. I would imagine if this was cached, then the updateTrackingCode() call shouldn’t take longer than 5-10ms.

3. When opening a search page wit hthe Piwik pixel on it, the function WP_Piwik\TrackingCode::applySearchChanges() re-executes the search query and slightly modifies it, which circumvents the query cache. On the blog of our customer with 100.000 wp_posts the search query takes 6 seconds, and then the Piwik plugin executes that query again for another 7 seconds runtime. See this callgraph information here where you can see the query on the right including the stacktrace leading up to it:

https://s3-eu-west-1.amazonaws.com/tideways/img/wordpress/WP_Piwik/piwik2.png

The fix in our case was to modify applySearchChanges() not to count the number of posts by hardcoding it to 0. But i think a better way would be to re-use the count from the first query.