By stuart6 on
Hey,
Could anyone recommend how many sites I could run from a single codebase? The sites will be low volume and bandwidth/space/server power/dbs are plentyfull. Also how many installations should I have in the same database on these low volume sites, with different table prefixes of course. My host is running linux and I have a relseller account. I know this is kind of vague, but I just would like to know if anyone has opinions/estimations on the matter.
Thanks in advance.
Comments
Doesn't matter
There will be no performance difference no matter how many sites there are, up to a point - if you have thousands and thousands of configuration files, it's conceivable that the directory lookups to find them will get a bit slower, but that won't amount to much, especially if you have a decent filesystem with good dir search times.
Same applies to the database - the load on the DB server is the same whether you use two databases, or one database with two sets of table prefixes, except perhaps at pathologically huge numbers.
Unless you're intending to run more than a thousand or two sites, do it however is most convenient for you.
Thanks for all your
Thanks for all your feedback. The site will be running around two thousand different config files, I will be sharing certain tables on the installation and some will be site unique. I will do some sort of testing (will be hard to simulate) but I might always just wait and see what happens.
--
Stuart (http://purplestain.net)
Too many variables
Well, there are too many variables to give a generic answer. There is the CPU speed, the memory, the disk speed, how many disks, ...etc.
Having said that, I have 3 sites running from the same code base, and the same database (using prefixes). One site is very low volume (100 page views per day or less), one is medium (1,100 page views a day), and one more than that (1,700 page views per day). They run nicely with not problem from a single hosting account, with no bottle necks or such.
So 3 seems to be a safe number, and perhaps 5 as well, since you mention they are low volume. Maybe tens of sites as well.
Remember that there is a price to pay: when you add a module or do a Drupal upgrade ..etc. it affects ALL SITES. So be careful of the maintenance overhead that you will have to put, and the all or none situation you are in, as opposed to having each site in its own directory, which brings nice partitioning but more work (you can upgrade one site and not the others, but have to look after several codebases).
It is all trade offs anyway.
--
Consulting: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Kbahey: it doesn't have to
Kbahey: it doesn't have to affect all sites. The core directory will have the main shared modules, but if you create a "modules" directory in the directory where settings.php lives for each site, those will only be loaded for that site. In this way, you can even override another module.
It is suggested that you in fact just keep Drupal core in the main directory, and put contrib and/or patched core in the per-site directories.
You are right
You are right. With 4.6 this is the case. Each site can have their specific modules.
However, if he has 15 sites, and a module is needed for 12 of them, it does not make sense to replicate it 12 times under sites. It is more rational to put just one copy under modules.
My comment was more to the effect that running from a single code base means that a change in that code base (modules or .inc or any other component) will affect ALL the sites.
If he upgrades and it gets botched for some reason of the other, all his sites are down.
Just pointing out the possibilities, so he can make an informed decision.
--
Consulting: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Use symlinks
We have our modules directory seperate, and just link the modules to the right sites as needed.
--
The future is so Bryght, I have to wear shades.
That would not solve the main issue
The main issue I was mentioning is that since they share code (either by copies or by symlinks), then they are all susceptible to botching up at the same time.
--
Consulting: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
What about 'files' and 'images' directories?
Are there any concerns with multiple sites sharing the same 'files', 'images', etc. directories? Is there even a way to keep these separate like with modules and themes?
: z
Make them separate.
Make them separate.
Create a separate directory for each domain, and then make sure to set each one in the admin menu to the one you want it to go to.
This way, they are isolated from each other completely.
--
Consulting: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Does loading a module in the code base activate it?
I've not installed 4.6 yet - but would like to know, if you add a module to the common code base does this automatiacally activate it for all sites, or does it just make it available? Don't you have to switch on the module in each site before it comes into effect?
Yes
Yes.
Just having the module laying around does not activate it. It is just made available.
You have to go into Admin -> Modules and enable it in order to take effect.
This applies to whether you are running one site or a thousand. It will not be enabled on any site unless it is specifically enabled in it.
One precaution though: if you modify a module (e.g. take out a link for example), then that change affects all sites that share the codebase unless you make it configurable via an option for example.
--
Consulting: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Modules and activation of those
So this means that multiple sites with multiple dbs still share the same settings for modules? Activating a module in one site's backend activates it for all sites?
No
If every site has its own database, or its own set of tables with prefixes, then each site is independant.
They share the programs, but not the data.
So, a module can be enabled in one site but not another.
Where you have to be careful is that a code change in a module will affect ALL SITES, since only one copy of the module is used.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba