1

To illustrate:
I have a multisites with a shared db edit.example.com and site.example.com. They share many tables but do not share all (a work in progress to determine what exactly need to be share). For example, the system table is not shared in order to be able to control what modules need to be enabled across all, on edit.example.com only and on site.example.com only. Does this can help performance? Is this a good idea or is it just adding an extra level of unnecessary complexity?For example I see caching becoming a problem because cache_page is not shared, or even if it is shared.

If there are any references out there please refer me to it.

Improve this question
  • Sharing tables I think is a recipe for disaster, I have only bad experiences with it. It's a quick hack, but not a nice solution. However, splitting Drupal in two sites, one for backend and frontend, I think is a great idea, something I've been meaning to implement for a long time. I even have a prototype of sorts in my local machine. For it to be worthwhile though, it should be a fairly large and complex site. – Letharion Oct 22 '13 at 17:25
  • if sharing table is not a good idea, how do you share content? Why would I split it anyway? – awm Oct 22 '13 at 18:19
  • @Letharion do you think splitting like that is any better than proper use of Boost? – Mołot Oct 22 '13 at 20:49
  • Wrote up an answer. @Mołot I think all of my points can be considered in parallel to boost, would be interesting to hear your opinion. :) – Letharion Oct 23 '13 at 9:14
  • 1
    You're completely right, that there's no simple solution that fits all cases. But there are still cases where this could make sense. Strictly speaking, the OP isn't asking for opinions, although I agree that the question could be worded better. – Letharion Oct 23 '13 at 9:26
1

Is this a good idea or is it just adding an extra level of unnecessary complexity?

There is no functional advantage of creating a multi-site for the purposes of separating content administration, as that will add an unnecessary level of complexity.

Some of the issues include determining what tables to share (which you've identified). Another common scenario is that content will be rendered differently depending on the site, leading to troubleshooting nightmares. An unscrupulous developer can have multiple versions of the same module in the site code, which creates head-scratching differences.

A single site is significantly easier to manage and ensure that administrative roles and permissions are logically set given your needs.

It can be helpful to have a distinct administration theme to visually enforce the difference between a normal and administrative roles. It's possible to specify a role per theme - https://drupal.org/project/role_theme_switcher for example.

Improve this answer
1

On a large site, I feel there are multiple problems can that be addressed by splitting a site into a "frontend", and a "backend" site. Different use-cases might find it beneficial to split along some other axis.

  1. Security: When the administrative users and roles are mixed with the non-administrative ones, the risk of privilege escalation is massively increased. Forcing a separation between the two adds a strong layer of protection.

  2. Performance: A Drupal bootstrap is heavy. When select count(name) from system where status = 1; returns some high 3 digit number, it can be very expensive. There's multiple sections across which one could split the modules, but a "admin"/"non-admin" should be a fairly common way that's useful. This makes the bootstrap cheaper, invokes fewer hooks with each invocation and generally performs better.

  3. Stability:

    1. When a large number of modules are enabled, interesting side-effects slowly start to pop up. Module X invoking hook Y was completely unanticipated, simply because the number of interactions between modules grows exponentially. Most of the time this will be what you want, and other times it will be innocent at best. Sometimes, it will bring your site down and you have no idea why.
    2. A large site will often be performing more than one tasks. Does it really make sense to disable all of that functionality because you need to put the site in maintenance mode, or worse because the site went down unintentionally. If large and important pieces of functionality are split up, they can fail gracefully independently from each other.

Is this a good idea or is it just adding an extra level of unnecessary complexity?

Of course, running two sites, and keeping their content in sync, say with services, is also a lot of work. So I don't see this as relevant for the average site, it's to much work for to little benefit. Whether or not it's "unnecessary" is a decision that varies from site to site.

Improve this answer
  • Are there any case studies you are aware of? – awm Oct 25 '13 at 20:20

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