PHP Developer's Journal

In a previous post we showed how we hooked up our blog's WordPress application with the new Compuware APMaaS offering. Since WordPress is a PHP application we use PurePath for PHP to monitor it. We highlighted that we got an alert about a response time violation on some of our blog posts - which is shown in the following screenshot.

Dynamic Baselining detects a significant violation of the baseline during a 4.5 hour period last night

In this follow-up article I want to show you how we get to the root cause of this problem which turns out to be a third-party WordPress PHP plugin that detects Bad Requests including requests from Bots that try to put spam messages in blog comments.

Step 1: See PHP Performance Hotspots
For the selected time-frame, we open the Response Time Hotspot dashboard. This shows which layer of the PHP Application has the highest performance contribution.

The high-level performance hotspot shows that most of the time is spent in core PHP functionality.

Step 2: Pinpoint the problematic method
A click on the PHP layer shows us that the Sleep function is the biggest contributor to this performance hotspot:

Turns out it is the Sleep function that gets called from one of the plugins we use to identify Bad Requests.

Step 3: Identify the actual request
Let's have a look at one of the transactions where we get to see where the sleep method is actually called:

We see where the plugin detects the bad behavior and also the log message it writes to MySQL.

We also get access to the web request details such as IP Address, User Agent or actual URL and Query String:

The details show origin information about this bad request, e.g: IP, User Agent, URL and Query String

Analysis: Lots of Bad Requests reduces WordPress performance
The Bad Behavior Plugin does a good job in preventing these bots from posting spam messages. What's interesting though is their approach of putting the request to sleep for two seconds. If we have a lot of parallel bad requests we have a lot of threads that are blocked in wait. This will impact "real" users who want to access the blog as the web server might not have any available active threads. A different approach would help. If you have a suggestion for a better way to handle bad requests to avoid the blocked threads issue, let us know in the comments.

If you want to know more about performance management for PHP check out the blog from Klaus on Exploring the PHP World with PurePath Technology. If you are an existing Compuware APM Customer check out our dynaLearn Webinar on First Steps with PurePath for PHP.