I need recommendations for a scalable web host for a high volume WordPress web site. For my purposes, high-volume might be 100K-500K visitors/hour. Might think towards a 1M/hour burst rate as a "high water mark."

I know WP isn't the highest-performing platform out there (ha!), but it's non-negotiable. I can do "the usual optimizations" (e.g. put static files in a CDN, run and follow the advice of performance analyzers like YSlow, etc). But it will still be WordPress, and there will be a dozen or so plugins involved.

So, where to host the site? Most "what's the best WordPress host?" discussions seem to focus on lowest-cost. I need the opposite. What are the high-volume, scalable, or clustered WordPress hosts with which you've had great experiences?

  • FYI, I asked this question first on stackoverflow.com, before it being suggested to post here. So far, WordPress.com VIP hosting suggested, but it has limitations. (is.gd/k1VC7) Commented Jan 3, 2011 at 21:59
  • You really don't need to use link shorteners here. Please just paste in the full real SO/SF/SE link. The site will take care of shortening for you. stackoverflow.com/questions/4587114/…
    – Zoredache
    Commented Jan 4, 2011 at 0:40
  • Have you already exceeded the limit on other existing webhosts? Or are you just wanting to future proof
    – TheLQ
    Commented Jan 4, 2011 at 1:16
  • Just out of interest, how big is a single page request/response? Commented Jan 4, 2011 at 10:03
  • When the site came to me for performance assistance, the initial uncached homepage response approached 2MB. Ze-ouch! I immediate cut that by 500KB and drove a bunch of the static files to a CDN. We were still serving several hundred KB per visitor. Unfortunately, the site was in production and load was rapidly spiking, limiting my freedom to change things on the fly. Commented Jan 4, 2011 at 15:09

6 Answers 6

Dedicated, Dedicated, Dedicated, Dedicated </steveballmer>

Ok, that's got that out of my system. If I were seriously considering a site with traffic as high as this, and really, 500khits/hour is a LOT.

I'd really really consider building my own network and cluster to host it. I'd star off probably with a 4 node system. 2 frontends running Varnish Cache, and 2 backends running both Apache and MySQL as the backends. Do circular replication between the backends, and run memcached for the session synchronisation.

Or you could put the Varnish and Apache together on the servers, and have the database servers doing database only. Come to think of it, this might be a better choice.

I have massive fears about high traffic sites on virtualised servers. Mostly because of IO performance, but also because it can be quite detrimental to the performance of other virtual machines which are on the same server, probably not your concern, but it does mean that other people's traffic can potentially interfere with your site.

WP isn't as bad as you think. You will have to make a lot of optimisations, cookieless domains for media, and all of the things you mentioned will help. You're gonna need 2 layer caching, or 3/4 layer perhaps. CDN, ReverseProxy cache, and also might benefit from querycaching with memcache, as well as opcode caching with APC.

There's a lot of small optimisations that can be made, which will vastly increase performance, and they're all worth investigating.

VarnishCache makes a great reverse proxy cache, but also a very fine load balancer too, and believe me, you will want more than one backend server. If your website is important, and uptime means something to you, (does it make you money?) then you'll definitely want more than one server.

Come to think of it, if you're delivering LOTS of media assets, images etc, I'd definitely consider another couple of servers, probably running nginx instead of apache, serving media.yourdomain.com, or a completely different cookie-less domain, like the sstatic.net domain that's used on the stackexchange sites.

Here's one example of how to do it, but you'll have to change the IP addresses for ones outside the RFC1918 ranges, to publicly routable IP addresses ;)

example server configuration

I'm gonna nip this in the bud before anyone complains about multiple A records. Without going very layer 3, and doing the high-availability side with BGP, or a GSLB, doing unintelligent load balancing with round-robin DNS is a nice way to go about it, not too expensive, actually, very inexpensive in comparison. You can do slightly more intelligent DNS with services like Dynect, which will perform some level of host checking before sending requests to your load balancers.

If you choose a good dedicated server host, they might do some, or all of the above for you. Given that you're expecting quite a lot of traffic, I can easily say that a cheap dedicated server ( less than 200-300 USD/month) is likely to be a false economy, and unable to support the levels of traffic you're expecting to get.

  • 6
    God, I hate mspaint. Commented Jan 4, 2011 at 0:01
  • @tom-oconnor Graphviz (dot) makes life a lot easier for simple things like that.
    – Scrivener
    Commented Jan 4, 2011 at 2:49
  • Really? Graphviz? I think i'd sooner install Dia on my laptop. Commented Jan 4, 2011 at 3:04
  • 1
    Upvote for 'Internets'
    – atx
    Commented Jan 4, 2011 at 5:33

Syed Karim asked: "Where/how did you end up hosting the site..." so here are my "notes from the front":

I didn't find any "automagical" service or solution. Wordpress.com VIP Hosting, WP Engine, and a few others look pretty interesting, but didn't fit this bill. So we hosted directly on Amazon Web Services (AWS).

We used (a few, big) EC2 server instances + Elastic Load Balancer + S3/CloudFront offload of I/O + optimization/minification + caching + CloudWatch Monitoring + SNS notifications + Python/bash automation/scripting + replication based on Mercurial.

The TL;DR details:

This site was a flash-mob site for an event of 1M+ people. It had only nominal visitors 15 days before the event, but then started accelerating into a fierce-slope, aggressive climb at T-3 days or so. With either Google Analytics or site performance monitors, you could watch load notably increase hour by hour.

We used EC2 servers, running Ubuntu "Natty Narwhal," MySQL 5.1, and WordPress 3.x. They were fronted by an Elastic Load Balancer. We had to shift DNS to Amazon's Route 53 service to make ELB work right with our primary domain (e.g. domain.tld rather than www.domain.tld).

For the servers, we preferred to scale up more than out in order to avoid the many complexities and potential failure modes of shared/replicated/clustered MySQL and NFS/CFS file pools. We could and did scale out, but in a "eventually consistent" and "all nodes use their own local storage" way. Site changes were made to a master server, then file and database changes were replicated to the rest of the WP pool. Replication was handled by a combination of Mercurial and SCP (there are fancier ways, these are simple and worked great).

In this configuration, eventually consistent <= ~3 minutes. That is, some users could see older content for a few minutes after it had been updated.

WordPress under load wants CPU much faster than memory, so we ended up vastly over-configured on memory. But we needed the CPU, and the price/complexity tradeoff was right for the limited number of hours we were in peak operation.

We considered an autoscaling configuration, but knowing the short duration of peak loads and the likely demand curve, and having good performance metrics and alarms (starting with CloudWatch and SNS), we chose manual scaling--yet another successful KISS choice.

The most common scaling operation was activating the next-largest-size instance, auto-loading required software, auto-replicating site content to it, and adding it to the ELB group. Starting from scratch, instance activation typically completed in under 3 minutes. With human confirmation the server was operating correctly and adding it to the load balancer, scaling up took perhaps 5-10 minutes in total. We would typically then quiesce the server instance it replaced. In the same 5-10 minutes, we could have spun up a few dozen new servers; we tested but never actually needed to deploy that.

We ran instance size all the way up to High-Memory Quadruple Extra Large Instance for the final full-peak load. We considered the even higher-CPU, higher-network-bandwidth Cluster Compute nodes, but did not deploy there because they require a different Linux build (the Amazon AMI, based on Red Hat/CentOS rather than Ubuntu), and we didn't want to invest in build automation or QA for a second software foundation.

We used S3 for files, with clients accessing it through a CloudFront distribution (i.e., S3 fronted through a CDN) to offload I/O. Going by the numbers, aggressively using I/O offload is the most important thing we did. It was also the simplest.

We optimized/minified JS, CSS, and PHP files for WP themes and plugins as best we could. Such changes toy with breaking the code, so we used Mercurial to track changes, and immediately back out any changes that broke the site. The designers had, unfortunately, chosen some plugins for image galleries and displaying the Twitter feed that were great when you get 50 requests an hour, but not nice in a scaling config, zapping right through your CPU and Twitter API allotments. Seriously, Twitter does not want you banging on their door 100+ times a second! Failing to find a Twitter feed plugin or service that was guaranteed scalable, I wrote my own simple caching mechanism. The image gallery we could't fix without changing the look in at least subtle ways, so we just bought more CPU to compensate for its bad design. (Next time: Designers, please select one that uses JS only, not PHP!)

We used YSlow, FireBug, and Google Chrome's Developer Tools to guide the optimization process.

We used the W3 TotalCache to reduce site load. Unfortunately, site design wasn't compatible with full caching (broke some plugins). We didn't have time to fix those issues, so we limited caching to what could be done safely, and again, bought more CPU time to compensate.

Most of the automation was accomplished via either Bash shell scripts or Python programs using the excellent Boto module/API. We considered using higher-level provisioning enablers like Fabric, Chef, and Salt, but various glitches we encountered said "we're awesome, but come back and try us again a bit later, ok?"

The results were excellent. We never went down, and never bobbled under load. We were ready for and could have handled 5x or 50x the load we received. There are many things we could have done more elegantly. Some of those would be desirable or even necessary on services that have different requirements--for example, high load over longer timeframes, greater load variability or unpredictable spikes, etc. But the many KISS tradeoffs worked well, scoring a practical win with modest DevOps effort and low execution cost.

My biggest regret is we didn't automate the process of detecting content changes and replicating them throughout the fleet. We required manual coordination between site operators and content owners. This worked ok, given the short peak window--but it was onerous. If I had it all to do over, watching the master for file/database changes and auto-firing the replication process across the fleet would be the #1 upgrade. (That would have the secondary benefit of greatly increasing the scale-out-ability of the enterprise; we could then use more smaller, cheaper server instances. An autoscale configuration would then be more highly leveraged.)

  • I should also mention a clear downside of this approach: It takes AWS, Linux, WordPress, etc. technical skills and attention. A great virtue of providers like MediaTemple or WP Engine is that they take such complexities / skill requirements out. YMMV. Commented Apr 6, 2012 at 18:05

VPS.net is a completely scaleable solution with high fault tolerance. It's inexpensive while being powerful and flexible. MediaTemple is another good provider because you can start with a less powerful Virtual Machine and then scale right up to your own server(s) with basically the click of a button. You should be looking for a provider that can quickly scale horizontally (redundancy/cluster) and vertically (more storage/CPU/RAM).


We use Rackspace Cloud, it's scales really well for our needs. Don't confuse it with Cloud Sites, but rather Cloud Servers. Basically you build your own cluster, and you can scale it however you want.

I run a WordPress only hosting company, but honestly, I haven't come across the amount of traffic you're talking about, so I don't want to put my hat in the running, I'd be more than happy to help you and learn from your experiences as to what worked and what didn't.


For High Volume WordPress Hosting I would go with WordPress VIP

WordPress VIP Hosting runs on the WordPress.com backbone which is load balanced across 1200 servers in 3 data centers.

what you get:

  • Your site running on the WordPress.com grid (over 1,200 servers in three data centers)
  • Unlimited space and bandwidth
  • 24/7 IT support
  • Content Delivery Network and hourly backups
  • Enterprise-level Akismet spam protection
  • Optimization and security feedback on your site’s theme for a faster and more secure site
  • Integration with WordPress.com features like Blogs of the Day, My Comments, Tag Surfer, and Gravatars
  • Promotion of your new blogs on our Publisher Blog
  • Sitemap and News Sitemap for better search engine and Google News exposure
  • People logged in to WordPress.com will be logged in on your domain, making it easier for them to comment on your blog


starts at about $2,500 a month.


I can't speak from any personal experience, but WP Engine was founded specifically for this question.

Not the answer you're looking for? Browse other questions tagged .