I'm considering Mercury/Pantheon for an existing Drupal 6 site that I'd like to port over to Drupal 7. It's a real estate site with about 30,000 listings, but should be expanding to over 200,000 throughout this year.
While the site is built on Drupal, there's a lot of custom code and much of it doesn't really make use of the Drupal system. For instance, the listings data aren't Drupal nodes and the way the data is presented on the listings pages and on a Google map contain a lot of AJAX and custom code. So really, it's a database intensive site which uses Drupal's database API, but not much else (ie. CCK or Views). I can see caching to be really difficult because there are so many ways to present a page. I.e. it could vary by City, Number of Bedrooms/Bathrooms, etc, so you can't just cache all those combinations of pages.
Questions:
1) Is there likely a lot to be gained from using Mercury in this circumstance?
- I assume it helps with static files like images, but because my site doesn't use a lot of Drupal concepts like blocks, views/cck, and many theming functions, does it miss out for some caching and other opportunities?
2) What can I do when migrating the site to Drupal 7, which will enable it to make better use of the Mercury stack?
- I assumed that having 200,000 real estate listings as nodes or in CCK would be a bad idea so I don't want to go that route.
3) I'm new to Cloud Computing, so I'm a bit confused with how it all works. Would the mercury stack enable a site to scale out to multiple servers/databases, rather than just increasing the RAM/CPU, etc on a single server?
- I was of the understanding that with EC2, when the site gets busier, you can scale it out to multiple server instances automatically, but I can't imagine how that would work. Does Mercury actually do something like that, or at least help with multiple MySQL instances (Master/Slave, etc)?
Thanks for any input you can provide!
Comments
I'm by no means an expert on
I'm by no means an expert on all this, but here's what I do know:
1) If you're not using APC, then you'll get a big benefit from that. If you have a lot of anonymous traffic, then Varnish will really help you. Depending on if you're using Drupal's Form API, Views, Menu system, etc, then the memcache integration should help.
2) Do everything you can the "Drupal way", and then you get to take advantage of all the different modules out there. If you hack things on your own, no module is guaranteed to not break your site, let alone add features to it. 200,000 nodes isn't that much - it's certainly large but there are much larger out there. There was a presentation on integrating MongoDB and Drupal 7 at DrupalCon last week - it would serve you well to check it out: http://www.archive.org/details/Mongodb-HumongousDrupal
3) Mercury gives you a all-on-one-box approach, but as you grow, it's really easy to separate out the chunks onto multiple servers. First, move MySQL to it's own server. If you outgrow that, move Varnish to it's own server. Next up is Memcached. My personal experience in MySQL clustering is one of futility, so I can't give many tips there. If you use the Tomcat+Solr integration, move that off to it's own instance. Separating all that will get you a lot of performance.
Honestly, you're so far off the beaten path, it's hard to tell how well everything would work for you. If you're having performance issues now, I'd look at enabling APC first if it isn't already. After that, look at setting up Varnish as a reverse proxy. That should buy you enough breathing room to start looking at how to rearchitect things the "Drupal way". Once you're there, then Mercury will most certainly help you get blazing performance, but it's all guessing until then.
HTH,
Justin
Thanks Justin, that really
Thanks Justin, that really does clear some things up for me!