Take the 2-minute tour ×
Drupal Answers is a question and answer site for Drupal developers and administrators. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers 2

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.

  1. Your sites.php file will get larger. You can specify which settings.php file should be used in the sites/sites.php file. 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.

  2. Your modules page will load slower if you put all modules in sites/all/modules folder, but only want to use them in a few sites.

  3. In core or shared module updates, make one wrong move and everyone will know.

  4. You can't use different robots.txt.

  5. In fact, you can't use just about any "known files". favicon.ico, apple-touch-icon, Bing verification file, oh gosh.

  6. Say hello to the complicated vhosts file and .htaccess for me. I'm a fat guy and so they should be.

share|improve this answer
    
Does it impose any overload to the sites? or make the sites slower ? –  Drupalist May 3 at 17:26
    
I'd doubt it will make sites slower all. More modules = slower modules page. That'll be all AFAIK. –  Ayesh K May 3 at 17:56
    
@AyeshK's point 3 is a serious concern, in my opinion. Whenever I've worked with mulisites, I've had nasty surprises with updates. –  Ollie May 4 at 11:44
    
Besides, it takes somewhat effort to run database updates for each site. As for drush, since it does db updates automagically, it doesn't really matter you are running multi sites or separate sites. –  Ayesh K May 4 at 14:32
    
the forth point is not true you can use this module drupal.org/project/robotstxt to create robots.txt for every site –  Drupalist May 7 at 12:43
show 3 more comments

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:

  1. sites.php isn't required.
  2. 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.
  3. So true. Definitely use drush to do updates. It will make backups beforehand and auto-rollback on failures.
  4. As @Drupalist mentioned: https://drupal.org/project/robotstxt.
  5. I think there are solutions here, at least for favicon.
  6. 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).
share|improve this answer
    
we have a main and very big website and lot's of other websites that are belong to our company. all of them are multi language and we are going to design different theme for each one. the only reason why we want to have one core, is to increase the main website rating, in this way when people visit the smaller websites, their statistic will be added to the main website. –  Drupalist May 8 at 7:28
    
Thanks for mentioning me:) Good point about OPcode caching. I think both methods have their pros and cons so it's up to the actual project to determine which way to go. (and that's a nice T Shirt you've got!) –  Ayesh K May 8 at 11:22
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.