From the article: "Apache would crash, especially when WordPress was really busy. 'We realized that it wasn’t super-stable under production traffic,' says Barry Abrahamson, a WordPress 'systems wrangler'"
Given Apache's track record and massive deployment, how could this be possible? Isn't it more likely that the Wordpress people were doing something wrong? Not that Nginx isn't great, but I'm bemused by the occasional suggestions I see that it's saving us from the suddenly broken Apache.
Barry Abrahamson actually responded to a similar critique in the comments:
----
Hi,
Barry Abrahamson here. A bit of context to my comment about the stability of Apache. We started WordPress.com using the Litespeed web server, but decided that we wanted to maintain as much of an open source stack as possible. We looked at lighttpd but had lots of issues with memory usage (leaks?) so we naturally turned to Apache. It worked mostly as expected performance and functionality wise. Keep in mind this was back in the Apache 2.0 days. Our problem was that deploying configuration changes which required a graceful restart under production traffic levels didn't work very well. About 10% of the time it either failed to reload the configuration, Apache stopped responding completely, or connections were dropped. Keep in mind that we were reloading ~1000 machines at once, but 10% is a pretty high failure rate. Yes, I know we could have removed machines from production, reloaded the configuration, and then put them back, but it's slow and error-prone, even if automated.
This is when we started looking at nginx. The nginx configuration reload works as expected all of the time, so that was enough to make us invest more time in the software. The transition was non-trivial since we had thousands of lines of .htaccess files which had to be translated to nginx configs, but it was worth it. Today, nginx is the "Swiss Army Knife" of our software stack. We use it for everything we can. I joke that we would use it as a database server if we could :)
------
As a side note, this may be the first useful comment on a Wired article I've ever seen.
Coincidentally, you probably could use Nginx as a rudimentary database at least since it can be extended with Lua. You can probably make it function as a database proper by using OpenResty. In fact, there are quite a few modules just for that purpose http://openresty.org/#Components
Apache rocks and is battle tested, the problem for them is that Wordpress is PHP which requires the process model worker for stability because PHP isn't thread safe and developers write shitty code assuming it is.
"Another option is to configure IIS to use PHP in FastCGI mode which allows PHP processes to be recycled rather than killed off after each PHP request and also allows you to run several PHP processes at once, making PHP much much faster with the added bonus that as it is using the CGI interface there is little or no incompatibility issues with PHP extensions. This is still the fastest way to serve PHP, and is the way the IIS Aid PHP Installer is configured to install PHP on your IIS Environment."
I looked at WordPress code and I don't recall seeing any thread stuff being used at all.
The problem with WP and PHP is not stability, but large, complex and suboptimal code. One of the reasons is because WP supports everything and a kitchen sink, and all the features were just patched over it as time went by.
I run custom PHP applications for thousands of users on Apache without problems. I am using nginx in front of it for KeepAlive and static files, which reduces RAM and CPU usage drastically. And it also makes everything faster for website visitors.
There's nothing wrong using both Apache and nginx, each has its purpose.
> I looked at WordPress code and I don't recall seeing any thread stuff being used at all.
You misunderstand. You don't need to write threaded code to write code that can't be used in a threaded environment. Think about using and accessing global or static variables in a threaded host environment vs a prefork process based environment.
PHP devs have adopted the practice of using Apache pre-fork rather than simply fixing their bad code because it hides their mistakes. On top of that, Wordpress being a huge plugin based community, you get tons of poorly written plugins that assume they're running in a single process environment because the authors simply don't know any better.
As far as I can tell, most PHP devs seem to think Apache only has a pre-fork mode; they write lengthy articles about how bad Apache is on memory not realizing the only reason it's that bad is because they're using the oldest and most resource hungry worker mpm. They don't seem to be aware Apache has other worker modules like threaded and evented that don't suck down ram like the prefork model does.
The cognitive load of understanding apache is greater than that of nginx; at least initially. And given that we're talking about people who are already taxed by the cognitive load of running a massively multiuser Wordpress installation...
Wordpress running on Apache with mpm-prefork - which is the default out the box - does insane bullshit that can indeed cripple the whole system. I run Wordpress via fcgid with mpm-worker by preference, because that way it's isolated in its own little sandbox to crap all over. Funnily enough, you have to run it that way in nginx too.
tl;dr the claim that Apache was the problem is Marketing Bullshit.
From what I recall, Debian currently defaults to threaded unless you install mod_php, in which case it insists you change to prefork because PHP still isn't threadsafe.
Well I think there's a few things going on here. I can tell you from experience that getting higher load WP sites working well takes a LOT of system memory, especially it seems, when you enable WPMU. It is hard for me to pinpoint one culprit for this, but other high-load PHP applications I've dealt with run just fine in standard apache (no php-fpm+MPM module X junk).
From what I've seen essentially Wordpress is just super heavy and tie that in with a more memory hungry MPM+PHP it quickly leads to Apache lockups. I don't think this is a problem with Apache at all, nor even a PHP problem but simply needing to have lighter-weight PHP applications, otherwise you are going to have to start resorting to tricks to get some good RPS counts out of your configuration.
My end of story: Wordpress is awful to scale in Apache and it's not an Apache problem.
It seems like they left some details out. "It was crashing with specific modules or configuration we were using" would be more accurate. The way it's worded makes Apache sound unstable, which isn't true in my experience & research.
If I remember correctly the details of why Nginx might be better at handling massive amount of clients is that it has event-driven architecture.
If you consider a slow client that consumes 1mb of html in, say, half a minute, an Apache thread(2.0)/process serving him would be effectively locked during this time. And thread/process has a relatively big overhead, both memory and cpu wise. Nginx, on the other hand, would just switch to serving the next client/clients, whos socket is ready (using epoll/select).
Given Apache's track record and massive deployment, how could this be possible? Isn't it more likely that the Wordpress people were doing something wrong? Not that Nginx isn't great, but I'm bemused by the occasional suggestions I see that it's saving us from the suddenly broken Apache.