Bug 1133341 - WordPress Quickstart Crashes under Load
Summary: WordPress Quickstart Crashes under Load
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: Templates
Version: 1.x
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Andy Goldstein
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-24 20:34 UTC by Cody DeHaan
Modified: 2015-06-12 02:18 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-12 02:18:47 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Cody DeHaan 2014-08-24 20:34:51 UTC
Description of problem:

Creating a WordPress quickstart (either scalable or not) under the highest PHP and MySQL versions (haven't confirmed for earlier) produces a WordPress installation that will completely crash under high load. If, for example you run a blitz.io session, or run apachebench, as few as 30-40 concurrent connections can be enough to crash the gear. 

Version-Release number of selected component (if applicable):

PHP 5.4
MySQL 5.5
WordPress 3.9

How reproducible:

Happens consistently

Steps to Reproduce:
1. Create quickstart of WordPress with PHP 5.4 and MySQL 5.5 (may work for all versions, haven't confirmed) and complete WP setup.
2. Run apachebench (ab) with 50 concurrent connections on WordPress homepage 

Actual results:

You end up getting the gear into a permanent 503 state. No apache, php, or mysql processes listed in htop when you ssh into the gear. OpenShift website inconsistently says either "Started" or "Stopped" when in this state. No messages indicating what happened show up in any logs (that I've found anyway).

Expected results:

If the gear can't handle the load, or apache/php/mysql stack crashes, it should automatically restart, or at the least produce some sort of actionable notification/log message about what has happened.

Comment 1 Andy Goldstein 2014-08-28 17:53:35 UTC
Hi Cory, what gear size were you trying this on?

Comment 2 Cody DeHaan 2014-08-28 23:27:33 UTC
This happened all on the free plan, and both on a single small gear, and on a small gear enabled for scaling (so I think two?).

Comment 3 Andy Grimm 2014-08-29 13:07:57 UTC
FWIW, this is, to some degree, expected behavior.  If the app periodically runs out of memory, watchman will restart it.  If it repeatedly hits its memory limit, watchman will eventually refuse to restart it.  Wordpress plugins sadly appear to be very prone to memory leaks, so load testing against a Wordpress app can definitely run into this situation.  (It is also possible that there's a bug in the code watchman uses to determine whether to restart the app.)

Comment 4 Cody DeHaan 2014-08-30 12:01:51 UTC
What kind of timeframe are the "repeatedly hits its memory limit" and "eventually refuse to restart"? I am seeing this behavior on a completely vanilla WordPress install (install the quickstart, give the site a name, and then try load testing), and it's possible to apply load, and have the gear crashed within 30 seconds.

Comment 5 Andy Goldstein 2014-09-09 13:29:13 UTC
I'm seeing this as well when using a small gear. If you use a medium gear, it holds up much better - I ran ab with 40 concurrent connections and didn't run into any issues.


Note You need to log in before you can comment on or make changes to this bug.