Multiple Drupal sites same server. How beefy?

mikeyparker's picture

We've got an issue with one of our servers that hosts multiple drupal sites. It was running just fine, and now there's a problem. We're looking to see if there are any other issues causing the server slow down. We're also reassessing our server requirements and so what kind of machine would we need - how many sites can you run serving what n number of requests? I know there's a bunch of variables, how many modules etc... but i'll try and be as specific as possible.

Current: 2.4 GHz 4MB Cache Intel® Core™ 2 Duo processor + 3GB RAM 2x 250GB Harddrives, Centos + PHP (5.2.6) & APC (3.0.19) + MySQL (5.0.45)

So say we wanted to host around 20-30 sites on a single server (drupal6), serving 500k page views per month across them all. With core modules + views, cck, panels, 4-5 with ubercart, and a few other modules so apart from the 4/5 ubercart about 10 modules per site.

So what can you realistically serve off a single machine?

Update the slowdown was caused by a spambot continuously posting comments to one of the sites, causing spikes in cpu usage and heavy disk access. Still though wonder what you can/ can't serve/ off a single machine.


On such hardware, with

Alexander's picture

On such hardware, with proper configuration and not soooo huge databases you should be able to squeeze out a seven digit number of page impressions per month.

In regards to spambots you might want to use something like ModSecurity in conjunction with fail2ban (for detection and keeping bots out on network level) and or include PHPIDS in your Drupal instances. A module for integrating PHPIDS to D is avaiable at:

One word of caution: I just love ModSec and use it on every server I can, but it takes some time to figure out what rules from the core ruleset don't work with your web apps and give you false positives. So it basically takes some time to get the config right.

Alex - Webseiter

really useful and pleasing

mikeyparker's picture

really useful and pleasing response "squeeze out a seven digit number", for me though think it's time we found a hosting provider to manage our dedicated servers for us :-)

APC cache size

joshk's picture

Assuming you run your core/contrib stack on a common codebase, if you have 30 sites with 10 modules in sites/sitename/modules, there's a non-trivial chance that APC is actually hurting your performance because it's impossible for it to cache all the files, and you're engaging in overhead trying to juggle the cache around. Check your cache fragmentation statistics and enlarge the SHM size accordingly.

In terms of what you can get off one box, the mix of logged-in/out traffic matters enormously here. As does your caching strategy. For instance, if you're serving mostly anonymous pages and your environment and expertise make Boost an option, you can likely do 10M pageviews in a day without breaking a sweat. Indeed, the limiting factor will likely be network I/O.

However, if all your users are logged-in and you don't have a good caching plan... then it depends on your queries, what pages they hit, what blocks are on, etc. Could be two orders of magnitude smaller.

There's just no apples-to-apples comparison for "how many users this drupal site will support". You have to dig into the stack to actually know what's going on. On the upside, if you want to run a high-performance or high-availability (or just plain popular) site, this is all stuff you need to be thinking about anyway. ;) |

thanks for your advice on

mikeyparker's picture

thanks for your advice on this, we're good on the apc front 3.19% fragmentation.

logged in/ anonymous traffic mostly anonymous, but we are building increasingly larger and larger sites with more and more community features, so something to definitely keep in mind.

i saw an article somewhere ( on using boost to improve performance.

i knew when i asked there was no straight answer to the question, but i have to say all the responses i've had have helped with my understanding/ confidence in the kind of setup you need to serve drupal sites. so thanks.

Good point, Josh. So if

Alexander's picture

Good point, Josh.

So if you're serving tens of Drupal sites from the same machine it may be worth thinking about a multisite installation. Not only would it make the codebase APC has to cache much smaller, but it would also be a great timesaver when it comes to updating.


The only small problem I

mikeyparker's picture

The only small problem I have with multisite is that of the overhead it can cause in managing multiple sites. locally we all develop using multisite and run this through svn to ensure that we can easily update live sites, each site on both or dev an live servers run single installs updated from a central svn repos. it's sometimes nice to be able to update a single site without having to think about breaking others. a discussion for another thread - i'd like to explore a better setup than we currently have anyway.

APC and separate Drupal sites

jeffschuler's picture

it's sometimes nice to be able to update a single site without having to think about breaking others.

I share your concern.

I wonder if there is a way for APC to recognize two functions or files as the same code, (in two identical but separate Drupal instances,) and only cache them once...?

We just upgraded some

erlendstromsvik's picture

We just upgraded some servers at work...
Two of the old servers were old single CPU celeron machines with 2GB memory and ordinary 7200 rpm disks (we buy a lot of cheap servers from Dell... :p ) One of these had served around 30-35 small Drupal sites without any problems (read: no customers complaining about performance).

In my opinion, the number of sites per server is dependent on what kind of sites you have/host. So it is more a question of when do your server/network start to buckle under the load.

Erlend Stromsvik - - erlendstromsvik @twitter
Ny Media AS -

Erlend Stromsvik - - erlendstromsvik @twitter
Ny Media AS -