The move to WordPress and the traffic that followed

On Tuesday evening, I converted this self-hosted site from a collection of simple, static HTML files to a full WordPress content management system.

And on Wednesday it received 93,112 page requests. Not the most my site has handled in a single day, but still atypical. All without any downtime, too.

Now, moving to WordPress had nothing to do with all the traffic. That was just a happy testing and validation accident.

The traffic surge all started with a post to Hacker News by someone I’ve never met. And I didn’t even notice the event until 8:45 that morning when their post made it all the way to the front page.

The funny thing is, this was a link to something I’d published and (mostly) forgotten about on Sunday. It was three days old by the time it got any real attention. Go figure.

Then sometime early Wednesday afternoon, John Gruber linked to the same page on Daring Fireball. Rene Ritchie piled on later with a link from iMore (and some damn good commentary). And other folks started linking to it as well.

Through it all, my server just kept humming along, not showing any significant memory load either.

What enabled all this reliability from a little WordPress blog? Just some common sense, really. But I can thank Guy English for at least one suggestion.

A few weeks ago when I first considered moving to WordPress, I noticed that Guy was using DreamHost for his blog, kickingbear. Since I also use DreamHost (they’re good people) and Guy’s blog was a WordPress site, I was curious if he had done anything special to survive his last Fireballing by our friend John Gruber.

The big difference in Guy’s configuration from mine was him using a virtual private server (VPS) instead of shared hosting. Good idea, I thought. Sure, it’s a little more expensive but there’s much more isolation that way, preventing the Apache HTTP server from getting too distracted.

Guy also suggested installing WP Super Cache, a plugin for WordPress. But I already made that a requirement. I’m not grotesquely stupid. Nobody should ever run a self-hosted WordPress site without some form of static page caching.

The other strategy I applied was a content delivery network (CDN) to offload stylesheets, scripts and images. This was easy since I was already using MaxCDN for my static site and WP Super Cache has built-in support for rewriting internal resource URLs to point at CDNs instead.

One thing I didn’t try was moving from FastCGI to XCache for PHP. I simply don’t have enough experience to know if that’s an advantage for WordPress, or the configuration tricks in making such a transition. But if you do, please comment on this post or contact me. I’m not above admitting ignorance or asking for help.

While 93,112 page requests seems like a large number for one day, it’s really only a little faster that one page per second on average. And the number of simultaneous users probably never got over 500.

A more stressful day on the site is still needed to shake things out and assuage all my fears about reliability. But this is a good start.

And a real incentive to write more.

15 thoughts on “The move to WordPress and the traffic that followed”

  1. PHP opcode caches generally help big frameworks like WordPress a fair bit since they tend to have a lot of shared code. It should reduce your response times, at least. If you’re looking for an opcode cache and you’re on PHP ≥ 5.5, I’d go for Zend Opcache though:

    It’s part of the PHP 5.5 and later codebase so, depending on your distro, the extension might already be available to you as a system package, so no compiling and maintenance for an external extension. Either opcode cache should be pretty easy to set up and they don’t require much fiddling, usually. Definitely stay with FastCGI/FPM either way, though. Installing XCache or enabling Zend Opcache shouldn’t require you to move away from it.

    If you’re really looking to get jiggy on interpreter performance, WordPress core is fully compatible with HHVM (as of…WP3.9 I think?). If you’re using new-ish Ubuntu, there’s an official repo for HHVM ( If not, you may have to compile it and that may or may not be worth the effort over a well-configured standard PHP. HHVM is very fast if your software is friendly to it, though it’s my understanding some WP themes and plugins may not be as compatible as core, so ymmv and all that. Here’s some benchmark comparisons of HHVM and PHP7:

    This will obviously require some changes to your web server configuration, but HHVM can run as a FastCGI handler as well, so you should be able to just direct the traffic to HHVM’s port/socket instead of FPM’s and go from there. I’ve never actually deployed it with Apache, so I can’t comment directly on that combination.

    In “high-performance PHP” deployments, it’s pretty rare not to see nginx these days, so you might also consider a move from Apache to nginx so you could leverage some cool stuff there. One you might check out is nginx’s FastCGI caching/microcaching to hold on to FastCGI returns and serve them like static files. It can make a big difference for spike-y loads by shifting a lot of the burden from your interpreter to nginx’s static file wheelhouse. This will be a little more fiddly to configure, but nothing absurd. There’s a little bit of a landmine around forcing purges of this cache, but depending on how often your content changes and how rapidly you want those changes reflected to users, it can be a non-issue.

    Anyway, just some lengthy thoughts from a once-and-likely-future PHP sysadmin. 😀

    1. I’d say that’s lengthy but useful.

      I’m on PHP 5.6 and I think my configuration already has OPcache enabled. But I’ll check. Will I get any memory savings disabling FastCGI if I first enable XCache?

      HHVM seems to be only available for “managed” WordPress installations at my ISP. Something I don’t want to use. Also, while HHVM can have much better performance, I may just wait for PHP 7 instead.

      Switching to Nginx is a possibility and my ISP makes that an option. But I understand, as you say, configuration is a bit more tricky if what you’re used to is Apache-style .htaccess files.

      Thanks for the feedback! 🙂

      1. There is a third party module, ngx_cache_purge from FRiCKLE, that will, alongside the Nginx Helper plugin from rtCamp, handle all of the purging considerations you might possibly have in a WordPress-on-LEMP setup. I’d highly suggest it if you’re still looking for optimizations—having the web server handle caching feels, to me, more elegant than having PHP do it.

        Either way, HHVM is going to buck a lot on a low-memory VPS. It’d probably even increase your load-times if you’ve got a server with 1GB of memory or less.

        nginx really isn’t too much harder to get accustomed to if you’ve already got the broad strokes of Apache down. DigitalOcean’s Justin Ellingwood has a ton of tutorials on using nginx, including one specifically geared toward making nginx and WordPress work in concert. It’s well trodden ground at this point.

        1. I will definitely look into Nginx closer now. Thanks for the pointer to that module!

          Yeah, HHVM has a reputation for being a memory hog. And I am currently renting a VPS with only 1 GB of memory. The good news is that, so far, I haven’t touched most of that RAM.

          Just found some of Justin’s articles. Thanks for the pointer to those, too! And it looks like some of the WordPress Core developers are on Nginx. Well trodden ground, indeed.

      2. XCache and Zend Opcache do the same thing, so you just want to pick one or the other. Their memory usage patterns are not identical but would mostly be predicated on how big a cache you allow them to have. FastCGI isn’t strictly related to either of them, it’s about how the web server and the application server talk to each other. If you’re using PHP-FPM as your FastCGI manager, then you can tune memory usage a bit by changing the number of worker processes and such, but the difference between the two opcode caches won’t matter for that.

        I’ve never used a Dreamhost VPS so maybe I don’t know what the deal is there. I assumed it was just a VM you had root on. If they’re making some specific binary choice between FastCGI and XCache, I couldn’t tell you why you’d pick one or the other off-hand.

        1. I just checked and the version of PHP I’m running was built using --enable-opcache on the command line. However, there is no zend_extension=/usr/.../ line in my “php.ini” file. So, I don’t think it’s running. I could configure PHP to do so, but I get the impression that DreamHost wants me to use XCache instead since there’s a checkbox to enable it in the Web-based configuration page for the VPS.

          1. That’s curious… You can throw a phpinfo() file up in your web-accessible folder temporarily to see what opcache options are set for the fastcgi handler. I don’t use Dreamhost’s VPS service, but I know on the shared hosting side with 5.6 the opcache is default enabled, though it’s set pretty conservatively. You should find a “Zend OPcache” section near the bottom of the phpinfo output with all the Dreamhost configured defaults if it’s working.

    1. As I wrote in that original post:

      While the free-range, handcrafted, artisanal nature of the HTML previously here afforded me a certain self-righteous smugness, a static generator can be pain in the ass to use every day. And though I liked the command line Magneto required, I didn’t want to spend all my time there with it.

      What I really needed was a publishing system easily accessible from anywhere — even mobile devices — to quickly create and deploy content. Which is the whole point of having a blog that people want to read.

  2. Hi, I posted it to Hacker News. I found and started following your blog when I saw an article your wrote about Steve Jobs, which was on the front page of Hacker News.

    1. Yes, I knew it was you, Mike. 🙂 I just didn’t want to call you out by name in case you wanted to keep your anonymity.

      Thanks for posting that to Hacker News and I’m glad you read my blog! Hopefully, I can keep you reading.

  3. I think on Dreamhost you’ll definitely see a performance improvement with your VPS vs. shared hosting. I moved a WordPress blog from a Dreamhost shared host to the cheapest $5 DigitalOcean VPS and it was still 3-4 times faster for pretty much everything – page loads, admin interface, etc.

Comments are closed.