I don't know if shared hosting is worth the trouble but a chain of events have brought me to giving shared hosting another chance for my Drupal sites. Last month, I pushed my VPS so close to the bleeding edge that it became unstable. While I was able to get my sites back online, the downtime clearly told me it was time to move my sites to a new server. While most visitors observed a performance improvement for my Drupal sites since the server migration, it's only now that I'm letting the cat out of the bag. For the past week, CMSReport.com has been under a shared hosting plan and not a VPS. I'm currently running my site using a budget shared hosting plan through my reseller site which is comparable to the hosting plans offered by GoDaddy.
I don't know how long I'll keep my site on a shared hosting plan but I am currently enjoying a break from the work, worry, and experimentation that comes with administration of a VPS. While I may go back to a VPS, I thought it would benefit some newbies and other Drupal users my experiences and thoughts on migrating my sites from a VPS back to a shared hosting plan.
Budget hosting revisited
Many of the budget shared hosting providers have improved their features and services over the past year or two. The shared hosting companies are finally understanding that the future is in Web 2.0 applications and not static pages. For example, many of the host providers now give you the choice of running your site on PHP4 or PHP5 as well as MySQL 4 or MySQL 5. In the past year, my shared hosting plan now allows for LOCK TABLES in MySQL databases (but has yet to grant account holders rights to CREATE TEMPORARY TABLE).Also, there has been an explosion of shared hosting plans which allow you to add multiple domains (websites) to your single shared hosting plan. In other words, budget shared hosting plans are giving you a little more control over the hosting features you have available for your site. However, are all these added features enough to run Drupal? I'm working on finding out that answer.
Drupal search, temporary tables, and alternatives
Luckily, there are alternatives to the core Drupal search module. Some have suggested hacking the core but luckily you don't have to go that extreme as there are other alternatives. One alternative I'm currently using is the the SQL Search (aka Trip Search) module. While the SQL Search module is not as robust as the core search module...it works and meets my needs.
Importing the database via phpMyAdmin
Let's just say that migrating a site from cPanel or Plesk to a unique control panel ran by the shared hosting company isn't painless. Luckily many shared hosting companies now offer phpMyAdmin as an alternative to their own tools for managing your database. However, not all is yet perfect in the land of databases administration.My host provider decided to limit the size of the SQL file you can import to 2 MB which is a problem when you have a 20 MB SQL file. Since many of the hosting companies use remote databases, it's likely you won't be able to change that limit they have set for you. To get around the 2 MB import limit I had to do two basic actions:
- Empty data from tables that are only being used to store "temporary" content. For example, I really didn't have the need to carry over the content of the accesslog table or the four cache tables in my database.
- Cut and paste the downloaded SQL flat file (now down to 12 MB in size) into smaller 2 MB files. I had to import six SQL files into the database when it was all said and done. Yet, it' was a pain in the rear-end to do but it had had to be done.
Multisite Drupal configuration
First, what is multisite configuration? From the Drupal 5 install instructions:
A single Drupal installation can host several Drupal-powered sites, each with its own individual configuration.
Additional site configurations are created in subdirectories within the 'sites' directory. Each subdirectory must have a 'settings.php' file which specifies the configuration settings. The easiest way to create additional sites is to copy the 'default' directory and modify the 'settings.php' file as appropriate. The new directory name is constructed from the site's URL. The configuration for www.example.com could be in 'sites/example.com/settings.php' (note that 'www.' should be omitted if users can access your site at http://example.com/).
In other words, if you have five sites and they all use the same contributed module then with multisite configuration you only have to upload the new/updated module to your server once and not five times. The Drupal handbook contains additional useful information about multisite configuration including how your directory structure would look like with the new configuration.
All this time, I never took advantage of multisite configuration so I decided to have fun with it this time around via the shared hosting account.. I've ran into a few problems such as how to not have the Drupal sites share the same files or images directory but this appears to be a problem not unique to my shared hosting nor necessarily a Drupal problem. Overall, I'm quite satisfied with how the multisite configuration is working my for site. I really can't believe I'm doing all this at about only one-fourth the cost of my VPS.
Concluding the first week of shared hosting
To be honest, hosting my Drupal account on a cheap shared hosting plan has gone better then expected. It still is too early to tell whether my sites will continue to function well without the benefits of a virtual or dedicated server. I also wouldn't be surprised if one day I get a call from the host provider that my Drupal sites are taxing their system.If the doom and gloom do become a reality, I can easily migrate my sites back to a VPS. In the meantime, I think it's important to see how Drupal does work for those who host their sites on budget shared hosting plans. After all, if you're a newbie to CMS and testing Drupal for the first time you are likely going to install it via a shared hosting account before you consider forking the money over to lease some time on a VPS or dedicated server. I'm enjoying this experience and hope to not be disappointed in the near future with running Drupal on a budget host. Stay tuned.
Comments
Caching and searching
Bryan, you hit on a lot of points. First, I want to mention that one of the biggest complaints that hosts have about Drupal is the number of database queries it generates. I know, you know, and all of the Drupal developers know that it is a lot. This is the price, it seems, of having a system that can be configured and extended in so many ways, and the price of a decently normalized database schema.
Well, there is some relief available. I've recently released an advanced caching module which can significantly cut down on the database queries (it will cut them in half, at least), and boost the performance of your Drupal site, especially for *authenticated* users (the group that is least affected by normal Drupal caching). You have to be able to apply patches to your Drupal source code, but that isn't as hard as it sounds and no programming experience is necessary.
You can read more about advcache and some other exciting developments relating to high performance Drupal sites here:
http://groups.drupal.org/high-performance
As for search and temporary tables, you can have the best of both worlds. By using the views fast search filter, you get the benefit of the indexed search that Drupal has without the overhead of temporary tables. This module needs a little conceptual background, however. As most people have heard by now, the Views module is an incredible tool. What it does is let you set up some criteria that will result in a bunch of nodes. You can say, for example, that you want to see all story nodes that have the taxonomy term "foo". Or you can say that you want to see all blog and article nodes that were written in May. Things like that. There are then options for how the nodes are presented (in a list, in a table, in a calendar... lots of options), but the essence is that you get a set of nodes back from your view.
The views_fastsearch filter sits on top of that set of nodes that gets returned by Views and lets you do an indexed keyword search on it. So if you have all of the blogs and articles written in May, you can then search for "Drupal CMS" and get search results from the set. If you want to replace sitewide search with views_fastsearch, you simply define a view that returns all of your sites content as the result set (arguably the easiest view you could create), and then add the views_fastsearch filter. Whee! You've got indexed site search with no temporary tables.
Views Fast Search
Robert, thanks for the suggestion about using the view fast search. I'll have to give it a try when I get a chance. It's a rainy day here in the northern plains so I'm using my indoor time to work on the "family site". It's a Drupal site mashed with about five years of photos, various galleries, old HTML pages, and a bunch of code written at the eighth-grade level. I'm planning on making it a simple Drupal/Gallery site.
I'll have to take a look at the high-performance group too. Currently, it looks as if the group site is either getting an upgrade or having some database problems.
Thanks, Bryan
Nice trick Bryan,
And thanks for doing this. I don't have a VPS server available and it is nice to know that my sites may not implode if they become busier.
take a Big Dump
I had a sql file upload limit of 2mb for a shared host and skirted it by using Big Dump. It worked perfectly for a 12mb sql file.
http://www.ozerov.de/bigdump.php
Nice article.
Excellent article, Bryan. I was wondering why you kept asking us (your visitors) if we thought things were fast or slow. I didn't notice anything bad or good - so your switch appears very successful to me.
Robert's comments are also of interest and we will have to look into his advanced caching module. As both of you probably know, we switched from a cheap webhost with a remote mySQL environment because of the issues Robert is raising - the number of queries and database latency. So, we are on a VPS and it's snappy. Before, it was impossible with only four people online.
One other issue, Bryan, that was raised in Drupal lately is the PHP memory configuration. We had problems at 128M and set it to -1 so that the limit is removed. Twice last week, we had to reboot Apache due to PHP memory problems. I wonder if you might run into that?
Robert's comments about "This is the price, it seems, of having a system that can be configured and extended in so many ways, and the price of a decently normalized database schema." is absolutely correct. Spoken in less geek "To get something clean, you got to get something else dirty." Drupal has a great deal under the hood. The more server and/or knowledge you have, the better off you are. We've been very pleased with our site and are fortunate to have great hosting and HarryB!
Thanks much for your thoughtful and helpful blog. Your comments, as well, Robert.
Me Too...Nice Article
Good stuff. And to Robert...is there any hope that advanced cache and memcache functionality will ever make it into the Drupal core, where it properly belongs?
Advcache caching in core
@HarryB: One of the secondary goals that I have in putting together the advcache package is to get a lot more attention and in-the-field experience focused on these caching strategies. The path cache patch, in particular, would be a huge win, and it is sitting idle in the patch queue. So yes, I hope to see all of these get adopted at some point.
Get Drupal Out of the Search Business?
First, I'd like to say how much I appreciate the great work done in the area of Search in Drupal. But I have favored using stand-alone search tools to handle my public site search for a variety of reasons. Lately, I've been working on a project that makes use of the Solr search appliance for a very large-scale literature database:
http://www.ethicshare.org/
Solr's performance has been, well, ridiculously good. Our initial data set includes about 50k citation records, stored as Bibliography Module records. Search result times in Solr are in the 2/10 of a second range. Most of the overhead now is in assembling the Drupal page itself. I've heard that the Solr appliance scales pretty well too, even on rather humble equipment. I'm talking about millions of records (ex http://www.search.com/, http://reviews.cnet.com/, http://aleph.lib.virginia.edu/blacklight/).
I've also extended the Solr Module to include faceted navigation (the drill-down categories on the left), which Solr spits back to you along with the search results, all in straight-forward xml.
It would be interesting to me to see how much performance strain a third party search tool, like Apache Lucene/Solr or Swish-e, actually takes off the overall system.
Obviously, a third-party tool isn't for everyone. There are a whole host of requirements, and I'm not talking just about hardware. Perhaps the real show stopper for many is that you need access to install the utility, which won't be available on a shared plan (the original topic of this post). Others will chafe at the idea of having to manage yet another application/system, although my impression so far is that this is not a substantial burden.
Ok, there are my .02. I've enjoyed this post as well as the very informative comments (Thanks, Robert, I'm almost certainly gonna use the patches you've supplied. Kudos!).