Optimizing a Drupal website with lots of modules (80 or more) by splitting it up into multi-sites

Posted by NewZeal on May 4, 2009 at 10:12pm

Hi,

As we all know a Drupal site becomes less efficient the more modules are added to it. I found myself working on a site with 115 modules or more and found in one instance that Ubercart was loading css on every page load, and not only was this contributing to the overheads, it was breaking the site in some forms in IE. While e-commerce forms a small part of the site functions, most of the site does not need it at all, so I looked at the idea of splitting the site into subdomains, each with about 40 modules or less.

This is a simple multi-site setup as can be found here: http://drupal.org/node/147828 and my particular details are here: http://drupal.org/node/147828#comment-1550058, showing the tables that I split up, specifically system, blocks, menu and node_access along with all the caches and a few others. The result was a performance gain directly related to the number of modules. Stats are as follows:

Full Site: Number of modules
access control x2
admin menu
cck x 15
core optional x 13
date/time x 3
custom for site x 13
event x 3
imagecache x 4
invite
lightbox
creativecommons
simplenews x 3
messaging x 2
notifications x 3
nodeprofile x 2
organic groups x 2
other x 23 (including pathauto)
quiz
ubercart x 16
views x 3
wysiwyg
fivestar
115 modules plus

Split site: master domain
access control x2
admin menu
cck x 15
core optional x 13
date/time x 3
custom for site x 10
event x 3
imagecache x 4
invite
lightbox
creativecommons
simplenews x 3
messaging x 2
notifications x 3
nodeprofile x 2
organic groups x 2
other x 17 (including pathauto)
views x 3
wysiwyg
fivestar
88 modules plus

Split site: jobs subdomain
access control x2
admin menu
cck x 7
core optional x 8
custom for site x 3
other x 13 (including pathauto)
views x 3
wysiwyg
38 modules

The results for the split site show a consistently 50% speed gain for the master domain and a 100% speed gain for the subdomain compared with the full site setup.

The main problem I had to overcome (that I know of so far) is finding a way to share the navigation system across all the subdomains so that the site still performs as one. This is done through a module which is available here: http://webdev.passingphase.co.nz/?q=project/site-splitter

Comments

Shared tables have issues

Posted by kbahey on May 5, 2009 at 3:02am

While shared tables are acceptable in certain cases, beware that they have their pitfalls too. It is sometimes a life saver in the short run, but an architectural suicide in the long run!

If you share tables between sites, this makes it hard if not impossible to separate the sites to multiple machines as some of them grow beyond the current machine's capability. If you rely on data being shared between sites, you no longer can do that when you outgrow your server.
If you upgrade one site in a multisite install, and the tables are shared, then the shared tables will be upgraded too (e.g. schema changes, ...etc.). The next site to be upgraded may encounter issues trying to upgrade already upgraded tables. While in many cases this just means that queries fail, you cannot guarantee that that is all that happens.

A recent client facing growth issues had this same problem. The current architecture was for the sites to use the single signon module with shared tables so they can use ubercart with SSL. When they needed to separate the sites, they could not do it! 2bits.com recommended that they separate the sites, and use subdomains instead of full domains, with a wildcard SSL certificate for ecommerce to get over this. Still needs rearchitecting on their part of the overly complex setup they started with.

Note that multi site alone (without shared tables, i.e. each site has its own database), is much easier to uncouple and move off one site to another machine as the need be.

In your case, you perhaps can use ecommerce on a subdomain with some work (maybe OpenID?), and still reap the benefit of keeping the ecommerce separate and hence the other sites (with more traffic) leaner. The same goes for CiviCRM.

Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.

Thanks for the feedback. I

Posted by NewZeal on May 5, 2009 at 4:02am

Thanks for the feedback. I have read some of your optimization tips from your site and taken them into account so I am aware that you are onto it when it comes to this kind of stuff.

Your comment above starts with the assumption that these are separate sites when in fact they are not. They are one site and there is no intention to break them up. The only purpose for separation is to improve the efficiency of the site overall. I have thought of separating the tables more than I have done but at this point all parts are merged and separating them now would probably be just as difficult as it would be if there were 50,000 nodes so there is nothing at this point to justify the extra work involved.

Creating a multi-site for this purpose does involve some work and some entanglement between different subdomain names but the cost of having all the modules on the one site was proving just as complex. Most recently I found the user register form was losing its theme completely in IE, which was extremely embarrassing for both me and the client. I eventually (after hours) located the problem was with Ubercart modules (half a dozen of them) all loading their css on every page load and causing some kind of conflict. While I could find a simpler ecommerce solution the client is talking of having paid subscriptions and paid courses so it would seem easier just to use Ubercart but separate it from the rest of the action. At that point I became aware that the current 115 modules could well increase to 150 with the addition of all the features they want that have not been implemented yet.

I could not find a suitable solution to this problem and this is what I came up with. What do other people do to optimize site with large numbers of modules? Should I do the extra work and separate them completely? It's hard to predict how successful the site could be to be able to anticipate growth.

The different sections are quite separate from each other and could lend themselves to further separation: There is a wiki/book, a job listing, a groups section with articles/cases, and a courses section to come. The store is for donations, subscriptions and to take courses.

Kent Parker
Web development

Clearer now

Posted by kbahey on May 5, 2009 at 4:55am

Now it is clearer. They are actually one site and you creatively segmented it into separate sites. I have to say that is a good strategy for avoiding 100 modules on every page load, which is the bane of large sites (I woke up one day upset that a client I am helping with performance has 180 modules [or was it 210?]. Can't remember if it was real or a just a nightmare).

If based on the usage patterns, e.g. the parts less likely to be visited (e.g. ecommerce) separated out from the more visited parts, it should have the desired effect.

I have found that pushing back when clients ask for this module and that modules works sometimes, but not others. It really depends on the character of the client and the site itself. It is always the duty of the consultant to explain the drawbacks clearly, whether the client will accept it or not, so at least they are aware of the issues down the road. Worth a try anyway. And it is not only performance. It is complexity, difficulty of upgrades, waiting for upgrades, ...etc.

Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.

+1 for If based on the usage

Posted by shyamala on May 5, 2009 at 7:37am

+1 for

If based on the usage patterns, e.g. the parts less likely to be visited (e.g. ecommerce) separated out from the more visited parts, it should have the desired effect.

In your case, you perhaps can use ecommerce on a subdomain with some work (maybe OpenID?), and still reap the benefit of keeping the ecommerce separate and hence the other sites (with more traffic) leaner. The same goes for CiviCRM.

Logical split up of a single site to multiple sites would also create a good site architecture and help in defining the content better.

Main site: www.mainsite.com (Drupal site 1 + Feeds from site2 and site3)
Sopping site: shop.mainsite.com (Drupal site2 with ecom)
Job site: job.mainsite.com (Drupal site 3)
CiviCRM: Drupal site 4....

I am sure you must have used Devel module. It has really helped us in optimizing and understanding What queries run on which page and optimizing the same. What other optimizing techniques have you used.

Netlink Technologies Ltd
I blog and Twitter :)

Shyamala
Unimity Solutions

Yes, those are good

Posted by NewZeal on May 5, 2009 at 9:17pm

Yes, those are good comments: it also creates a coherent experience for users.

I wouldn't need feeds from the subdomains to the mainsite, since, at this point all subdomains share the same node and node_revision tables. This means that the same 'about' pages are accessible in both domain and subdomain as www.mainsite.com/about and jobs.mainsite.com/about. Since 'about' pages only require modules that are shared by both parts of the site then they are functional in both.

Any menu items that point to a function that is only available on one part of the site (eg jobs) I have to put in the full url: jobs.mysite.com. All my nodes are accessible from all subdomains, however the functions that accompany some of them are not, eg jobs, products. I may yet run into usability issues later on, I don't know yet, but at least I could separate out the node tables later if that becomes a problem.

I think that drupal.org is probably a good example of optimizing by this method, whereby the groups are on a subdomain. We all know that groups use up a lot of overhead and here we have Drupal groups at groups.drupal.org so the modules are not slowing down drupal.org. Also notice on Drupal.org that url aliases are not used, another technique to speed up the site I would say.

I have only used Devel at this point, but what really caught my attention was things like:
500 queries run in 200 ms. Page load time 4 secs

The queries are happening quick enough, but what is going on with the script!?

My first step was to install eAccelerator which produced a 100% improvement. Then I figured that all the Drupal hook calls would also be slowing the site down and that's when I decided to split the site and run tests. The improvement was immediate.

Kent Parker
Web development

301

Posted by kwinters on June 3, 2009 at 7:07pm

Re: the pages accessible from both domains...

This may not be desirable to allow, and I'd recommend using .htaccess 301 redirects to send those pages back to the main site if it can be done reasonably. In some of these examples, it would mean 301-ing from the e-com site to the main one for any path that didn't have to do with e-com.

When you allow 2 versions of a page, that could hurt you for SEO reasons (though hopefully the correct version will end up marked primary) and it could also just not work on one site if some hook is not available.

Some pages may be broken in obvious ways, but when it comes to shared db multisite, the thing that worries the most is that the lack of some node api hook will cause data corruption if someone accidentally edits on the e-com domain, etc. Right now the best solution I can think of is to maintain a separate admin.mainsite.com domain, which has every module and editing / configuring can only happen through that.

Ken Winters

www.coalmarch.com

Ken Winters

Thanks, for your comments.

Posted by NewZeal on May 5, 2009 at 6:54am

Thanks, for your comments. Hmm.. can't say I've had nightmares about 200 module sites, but this current client went to a lot of effort to secure and pay for a high performance server with unlimited scalability (apparently) so after I'd loaded the site with over 100 modules I thought, this is a bit of a wasted effort performance wise to have a such a hot server and have Drupal pouring cold water all over it and I figured the amount of time I had put into the site justified a couple of days to work out how to implement this. I believe my effort has been rewarded and I am about to suggest this to the client. Up to now I have not been very good about putting clients off new modules for performance reasons. There are so many variables.

I'll keep a record on this thread of the experience I have with this method for anyone who is interested. At present it is on the development server.

I would appreciate any feedback, potential pitfalls that anyone can spot etc.

Kent Parker
Web development