There are more than 100 sites that are supported by our company and they can be presented as sub domain as well. from technical perspective is it reasonable to run all of these sites using only one Drupal core? is there any drawback in doing such thing? or we should have multiple cores?
Technically, there shouldn't be. But even if I had enough server resources, I'd reconsider my approach. A few problems I can think about. Note that they are really small annoyances and there are workarounds. If each site of your network has to be a very serious site, and all you are expecting is less files on the server and ease of updates, I think it's a bad idea.
sites.phpfile will get larger. You can specify which settings.php file should be used in the
sites/sites.phpfile. That file will get larger with the number of sites in your network. However, in a age that you store 100 configurations in
$GLOBALS, this shouldn't be a problem.
Your modules page will load slower if you put all modules in
sites/all/modulesfolder, but only want to use them in a few sites.
In core or shared module updates, make one wrong move and everyone will know.
You can't use different robots.txt.
In fact, you can't use just about any "known files". favicon.ico, apple-touch-icon, Bing verification file, oh gosh.
Say hello to the complicated vhosts file and
.htaccessfor me. I'm a fat guy and so they should be.
Certainly, there is a cap where it makes more sense to separate the stacks for performance reasons.
@Ayesh K made several good points. There are ways to deal with most of these issues:
- sites.php isn't required.
- This is true. Sorry :) However, you can put modules only needed for [siteA.com] in
/drupal/sites/siteA.com/modules/. Then those modules won't show up in the other sites' module list.
- So true. Definitely use drush to do updates. It will make backups beforehand and auto-rollback on failures.
- As @Drupalist mentioned: https://drupal.org/project/robotstxt.
- I think there are solutions here, at least for favicon.
- Modular-style includes for your http server can help this. (look at what Aegir does for Nginx as an example).
Something that stood out in my mind in this discussion is OPcode caching. Using opcache, APC or similar, I think you will benefit from the single stack (multi-site).
It would largely be determining:
- How you want to best utilize your hardware for performance.
- If you can solve the issues mentioned by Ayesh (or they aren't an issue for your use).