1

I help manage a cluster of sites related to course curriculum. Each site is a separate Drupal 7 install with its own theming, modules, user list, content types, entity structure, and codebase - all of them identical (not shared, but replicated across all the sites). They all run on the same server as different Drupal instances. I'm not a huge fan of managing each individual site and its modules, libraries and theming, but this is the setup as I inherited it.

Now we are looking at adding a few sites to the cluster. This is an opportunity to organize differently, and I haven't found any adequate data on which method is better. These are my three choices as I see them.

  1. Multiple Drupal instances (the way we have it now).
    • Advantages:
      • If code for one instance gets broken, the others will continue to run.
      • Opportunity for separate userlists, taxonomies, etc. (Right now we are not leveraging this, but I suppose we might in the future.)
    • Disadvantages:
      • Every upgrade has to be tested and implemented on all sites individually.
      • Performance hit from running all those instances (cron runs, session variables, caches, etc.)
  2. One Drupal instance running Multisite.
    • Advantages:
      • One codebase means one set of modules to maintain.
      • One Drupal instance would smooth out the performance issues (maybe?)
    • Disadvantages:
      • Each site still has its own database, requiring separate userlists, taxonomies, etc.
  3. One Drupal instance with all the content in one place. (This is the way I'd really like to go.)
    • Advantages:
      • Much, much easier to maintain.
      • Performance savings? (This is what I really want to quantify somehow)
      • Only one site to upgrade when we finally go to D8...
    • Disadvantages:
      • Lose flexibility among sites' user lists and access levels. (I can get some of this back using taxonomy terms, but for now it's immaterial.)
      • Lose flexibility with content types and structure. (The sites are very nearly identical as it is, and the differences can be smoothed out in development.)
      • If one site gets broken, they're all broken. (Already true to an extent because all the sites are on one server.)
      • Performance hit from all that content being in one database?

What I'm wondering is, what are the performance savings for each option over #1 (the status quo)? Quantitative data is great, but even an explanation of where the savings come from would go a long way.

2

My recommendation is to go with a multisite.

Multiple Drupal instances and multisite are about the same in terms of performance (multiple databases). One Drupal instance will not scale as well and thus will not perform as well. The database layer is a bottleneck of Drupal that is hard to work around.

You can create custom code for taxonomies to make them shared across all multisites; users can use something like https://www.drupal.org/project/bakery. Doing this for multiple Drupal instances is a little harder to pull off in comparison to a multisite.

To do a shared taxonomy you'll need a new database connection in your settings.php pointing to a new db. This will hold all of your taxonomy_* tables; or you can designate one already existing db to be the master record. Then using hook_taxonomy_term_presave() and hook_taxonomy_vocabulary_presave() write the master taxonomy info into the correct db or if it already exists have it use that tid/vid. Then in hook_taxonomy_vocabulary_insert()/hook_taxonomy_vocabulary_update() and hook_taxonomy_term_insert()/hook_taxonomy_term_update() write the taxonomy info to the rest of the databases in your multisite. See taxonomy_term_save() and taxonomy_vocabulary_save() and use the drupal_write_record code to write. Use db_set_active() to change database connections. Have all multisites use the same settings.php file (symlink or include), and in there have a big array containing all your database connection info; create a path lookup function that uses conf_path() and readlink() if needed for knowing what db to connect to. You'll need to migrate all taxonomies before so they all match. This took a little while to code, about 2 weeks. The code I have is for D6 so it wont work for D7.

We used the shared taxonomy on around 80 databases using https://www.drupal.org/project/domain to give us 1300+ domains. It scaled very well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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