Debian Logo

375 Million pageviews for 15$ a month

375 Million pageviews for 15$ a month (on an Amazon EC2-Micro instance.)

This is part of our “Hackerspace Trials and Tribulations” series in which we blog about certain problems we’ve encountered while getting our HubCityLabs off the ground, and the solutions we found worked best for us. You can read the first post of the series here: Hackerspace Trials and Tribulations: Payment Processing

Back in late August, one of our articles, DIY PCB Etching at HubCityLabs was covered on Hack-A-Day. Almost instantly, our website kicked the bucket. At the time, we were hosting the website on a small vps provided by one of our members.

We quickly transferred everything over to a temporary Amazon EC2 instance, and were able to get back up in short order. Since then, we’ve moved the site into its current location, on a Debian EC2 instance, and we were able to optimize things so that we’d be able to sustain a rate of 375 million page views in a month (500000 pageviews/hour) on a WordPress-based site. This is the story of how we got there.

Hardware

Amazon lists the following hardware equivalency for their EC2 Micro instances:

  • 613 MB memory
  • Up to 2 EC2 Compute Units (for short periodic bursts)
  • EBS storage only
  • 32-bit or 64-bit platform
  • I/O Performance: Low
  • EBS-Optimized Available: No

OS

I decided to go with a Debian image (debian-6.0-squeeze-base-x86_64) since Debian is my favorite server distro. Once that was up and running, it was decided that we would be running on an Nginx/php5-fpm/php5-apc stack due to the limited available resources.

We ran a blitz, and quickly found our first problem. In nginx’s error log, we were getting a lot of “too many open files” errors. To fix, we appeded “fs.file-max = 1000000″ to /etc/sysctl.conf, and also set our values in /etc/security/limits.conf to “nginx soft nofile 10000″ and “nginx hard nofile 100000″. That seemed to resolve the issue. At that point we were able to get about 1500 pageviews/hour.

WordPress

For WordPress, we did 2 important things. First, we disabled WordPress’ internal cron by adding this in wp-config.php “define(‘DISABLE_WP_CRON’, true);”. Next, we setup a Debian Cron task to run the cron manually, on a schedule, instead of on each page load.

Next, we installed the WP-Super-cache plugin (there are other good ones too, like W3 Total Cache), and configured it for aggressive caching. At this point, Blitz.io reported 60000 pageviews/hour.

Varnish

We installed Varnish as a font-end cache to reduce the load on the web server even more. After a little tweaking, Blitz.io reported us being able to sustain 500000 pageviews/hour without errors or timeouts. At that rate, the system is still snappy on the shell, and page load times are more than reasonnable.

Conclusions

Hopefully this will help other hackerspaces, and people on a limited budget, to bulletproof their web hosting on the cheap. There are probably more tweaking that could have been done, however we do not forsee a need, as half million pageviews/hour is much much more than we can possibly imagine having.

Related Links

Installing NGINX and PHP-FPM running on UNIX File Sockets
10 Million Hits a Day on WordPress/Amazon EC2
Blitz.io
Linux/NGINX Too many open files
WordPress and WP-CRON

DanyO

DanyO is a hacker at the HubCityLabs Hackerspace. He has been a maker with a penchant for software and electronics for two decades.

More Posts - Website

Follow Me:
TwitterFacebookLinkedIn

  • Javier Constanzo

    Nice reading, but can you elaborate a little more on why you disabled the wordpress cron? thanks!

    • http://www.facebook.com/DanyOuellette Dany Ouellette

      It my belief that wordpress’ internal cron attempts to run on every page load. Tasks like scheduled posts, plugin updates, and other background tasks are evaluated at that time. Although not immense, I do believe that this increases load times a bit, and repeated for a lot of users, it might put some undue pressure on the system. So disabling CRON on page load, and having a CRON job run every X minutes, seems more efficient.

    • davidnlevy

      >Next, we setup a Debian Cron task to run the cron manually, on a schedule, instead of on each page load.

      If the Cron task loads with each pageview, you wind up with a big overhead as your page views increase. Using the external Debian Cron keeps the jobs running with a much lower overhead

    • https://www.tinywp.in/ Pothi Kalimuthu

      When we use Varnish in front *and* when a request is served by Varnish from its cache, then the WP cron job doesn’t even come into play. Only when a request hits WordPress, then the internal WP cron job will be triggered. I still recommend the use of external cron job without disabling the internal WP cron system, because only once Varnish fetches the content from WP. Once it puts the content in its cache for X number of seconds (or minutes or hours), during that time, if a post needs to be published, it can’t be published by the internal WP cron system. That’s why I recommend the use of an external cron job, even though I am against disabling of internal WP cron system.

  • Eduardo

    How much are you spending on bandwidth? Thank you.

  • filthysushi

    How come you chose Varnish over Memcached, for interests sakes?

    I have a similar set up to this on a SSD based 512MB VPS and am pushing it to 294 million visits a month, according to blitz.io using -p 1-250:60. I tried with -p 1-1000:60 and it managed to get to 1050 million visits a month, according to blitz.io, however there were 2 errors and about 500 timeouts which I’m trying to iron out.

    This isn’t using WordPress, but it is another php/mysql script called Prosper202 and the test link was a redirect.

    • hubcitylabs

      Apples and Oranges. Memcached is a key/value pair cache that’s usually used to cache data coming from the database (although it could be used for other things)

      Varnish is an actual web server, that you put in front of your httpd server. It caches and proxies the requests in a manner that lessens the load on your httpd server (in our case, nginx)

      • filthysushi

        Thanks for the reply :)
        Do you think its possible to have a set up where memcached is caching the database, varnish is caching http requests and APC is caching the php? Or is that overkill? :)

        • baobrien

          I don’t see why you couldn’t. If I was setting up something with that many pageviews, I probably would.

  • Pingback: Hackaday-proofing your hackerspace’s server - Hack a Day

  • Pingback: PageLines

  • Pingback: Hackaday-proofing your hackerspace’s server | Cool Internet Projects

  • Joel

    1. WP Cron isn’t actually loaded at every pageview at all. It is loaded
    at every point a plugin (or core) has requested it to load. Then it
    spawns a new HTTP-request with timeout 0 (this makes sure it is spawned
    without blocking IO, since it will timeout directly (but it continues in
    the background…), so the request doesn’t take longer to execute).
    However, badly written plugins might register a lot of events… Also,
    HOW does wp check if it has to run cron? Not sure about that, but it
    might occur a situation like this:
    Child 1: Wp cron? Nope.
    Child 2: Wp cron? YES! *child 2 runs wp cron*
    Child 3: Wp cron? YES! *child 3 runs wp cron*
    Child n: Wp cron? YES! *child n runs wp cron*
    Child 2: Wp cron finished, write(no_more_wp_cron, file);
    (child 3-n also writes no_more_wp_cron)
    Child n+1: Wp cron? Nope.
    Not
    sure if it’s called a race condition… but a lot of clients try to
    update a cache at the same time. I’ve had problems with this before, not
    with wp but actually with far more efficient systems in PHP with a lot
    of pageviews…

    2. Why varnish on top of nginx? Can’t nginx do the caching too, I thought that was one of the points it was great at?

  • Michael

    If you really could elaborate why you used varnish in front of nginx it would be great.

  • Pingback: An Amazon engineer had a little idea that turned into a billion-dollar business – Quartz

  • Pingback: An Amazon Engineer Had a Little Idea That Turned Into a Billion-Dollar Business « EDUCATION

  • Pingback: An Amazon Engineer Had a Little Idea That Turned Into a Billion-Dollar Business : Dead Dogan Teck-Talk

  • Pingback: An Amazon Engineer Had a Little Idea That Turned Into a Billion-Dollar Business

  • Pingback: An Amazon engineer had a little idea that turned into a billion-dollar … | o-hardware