By Andreas Grabner | Article Rating: |
|
June 23, 2013 01:00 PM EDT | Reads: |
9,892 |

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.
Published June 23, 2013 Reads 9,892
Copyright © 2013 Ulitzer, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Andreas Grabner
Andreas Grabner has been helping companies improve their application performance for 15+ years. He is a regular contributor within Web Performance and DevOps communities and a prolific speaker at user groups and conferences around the world. Reach him at @grabnerandi
- Why Do 'Cool Kids' Choose Ruby or PHP to Build Websites Instead of Java?
- James Gosling: "Java Is Under No Serious Threat From PHP, Ruby or C#"
- CFEclipse: The Developer's IDE, Eclipse For ColdFusion
- Exclusive Q&A with Jeff Haynie, Co-Founder & CEO, Appcelerator
- Java Kicks Ruby on Rails in the Butt
- Java Feature — What Is SCA?
- An In-Depth Look At The Zend Certified Engineer (ZCE) Certification
- AJAX and Atlas
- Open Source Database Special Feature: An Introduction to Berkeley DB XML
- Taking Linux, Apache, PostgreSQL, and PHP to Their Logical Extreme