How Many Sites Should I Have on a Server?

Summary

  • For small brochure style sites, we recommend no more than 10-20 sites on a 1 CPU / 2 GB server
  • For sites that require more resources like WooCommerce installs, we recommend 1 site on a 2 CPU / 4 GB server
  • It’s better to distribute your sites across more servers with fewer system resources (CPU/memory) than to jam many sites on a single, more powerful server
  • We do not provide technical support for servers that host more than 80 sites on a single server

Sites Per Server

Deciding how many sites you should put on a server can be a tricky business as there are a number of things to consider.

Full Page Caching

One of the most important factors to consider is full page caching. By enabling full page caching for a site, you lighten the load on your server in a big way. When a page is first requested, PHP executes, and MySQL is queried to retrieve and assemble page content, the page is cached and returned to the requestor. Subsequent requests for this page are then served from the cache, leaving PHP and MySQL out of the equation and yielding much faster response times (we’ve measured 5x faster) and far less server resource usage.

If you enable full page caching on a vanilla install of WordPress (default theme, no plugins), you essentially turn the site into a static site, the cache being your static files. As we’ve shown in our benchmarks, Nginx FastCGI Cache (SpinupWP’s full page caching engine) can serve upwards of 291 requests per second on just a 1 CPU – 2 GB virtual private server. We’ve had our sites appear on the front page of Hacker News and with full page caching enabled, they handled the traffic just fine.

Unfortunately, not every page on every site can be cached. For example, if you install the WooCommerce plugin, your cart, checkout, and account pages cannot be cached. And if you want to display the number of items in the visitor’s cart on every page, you’ll need to either disable full page caching entirely or come up with a solution for loading that cart information separate from the page load.

The limits of full page caching are not limited to WooCommerce or even to eCommerce plugins. If you’re running a membership site where your visitors log in and see personalized information, page caching will be trickier. If you’re running a forum plugin like bbPress, it’s going to be tricky as well.

For a site with pages that can’t be cached, it’s best to start it on its own server, monitor server resource usage, and see if it’s ok to put another site on that server or if you need to upgrade it because you need more resources for that one site. For help determining what server size to start with, see our Server Size doc.

For a site where all its pages can be full page cached, you can go with a 1 CPU / 1 GB server (the smallest SpinupWP allows). You might even be able to host a few more of these types of sites on that one server, depending on the traffic they get. We generally recommend not exceeding about 10-20 sites on a 1 CPU / 2 GB server.

Control

You can certainly get away with hosting 45 sites on a single server if you have full page caching enabled and you’re in full control of the server. If no one but you can even add/update plugins for the sites on the server, then the chances of a site causing problems with the server when you’re not expecting it is reduced dramatically.

On the other hand, if you’re hosting client sites, giving your clients access to their site files via SSH/SFTP, and allowing them to add/update whatever WordPress plugins they want whenever they want, you should expect problems at any time. A newly added/updated plugin could easily kick off background processes that monopolize server resources, introduce an HTTP callback loop, essentially causing a denial of service (DoS) attack on your server, etc.

There’s really no limit to the number of ways unrestricted sites can cause problems on your servers. If you’re going to give others unrestricted access to their site files, you should seriously consider putting them on their own server where any problems will only affect that one site. At the very least, you should keep the number of unrestricted sites per server low, under 10.

PHP Pools

Each site SpinupWP creates on your server is deployed with a PHP-FPM resource pool. What this means is that each site has a specific number of PHP workers assigned to it, and these workers take up memory on the server. The more sites you have on a server, the more resource pools are required, and the more memory you will need.

Active Cron Jobs

Each site on a server will have a server-level cron configured to activate WP-Cron. As you add more sites, this could lead to cron related CPU spikes, which may lead to timeouts and downtime for other sites on that server. Increasing the cron interval for sites that don’t have many scheduled tasks can help to reduce these CPU spikes.

Security & Privacy

Although SpinupWP sets up a system user for each site and enforces security isolation between sites via file permissions and PHP pools, sites on the same server still share memory. It is relatively easy for a site to access the memory space used by another site and read sensitive data.

If security and privacy are important for some of your sites, they should not share a server. However, if you’re hosting multiple sites for one customer, you could consider putting those sites on one server.

Monitoring Server Resource Usage

As a general rule, we recommend you try and keep server memory usage at 60% or below to allow for traffic spikes. If your server CPU usage or memory usage is consistently high then it might be time to upgrade your server. See Monitoring Servers and Sites for our monitoring recommendations.