MySQL

If you haven't already heard, Drupal 7 will default to using the InnoDB storage engine instead of MyISAM for MySQL (though a MyISAM database will continue to work just fine in Drupal 7). This is fairly substantial change within Drupal core, and as the thread in the issue queue I linked to shows, there were a lot of questions and apprehension about it. However...

...we are going to just skip over a lot of that apprehension and get down to point of this article - there's no good reason not to hop right into using InnoDB today on your Drupal 5 or Drupal 6 site. The rewards are; a possibly significant improvement in performance, a definite improvement in scalability (most highly trafficked Drupal sites have been using InnoDB for some time now because of this), and you'll start getting used to working with what will be more and more common in your Drupal-life, InnoDB.

I made this script and the database backup, dump, and SVN commit script because I was determined to spend as little time as possible doing sysadmin while setting up dev and staging sites, so that I could spend as much time as possible developing (e.g., the fun stuff). With one command the script can:

• 'svn up' a version controlled database, and upload it to your database
• Run queries against database to set preferred site defaults
• 'svn up' site docroot
• Copy over fresh "files" directory from another site (e.g., production). Note, not a good option if you have your "files" directory version controlled.
• Set owner:group file permissions on all site files

How to
The script should go in non-public, secure directory, which is somewhere below the site doc root. I haven't tried running it with permissions less than sudo, though it may be possible. Invoke by doing:

sh path/to/provision_and_install.sh

Download
provision_and_install.sh.zip

This script is useful for keeping a database within reach of an 'svn up' anywhere it needs to be deployed (e.g., dev and staging sites). In addition to creating a database dump, it also svn commits the database. I use it in conjuction with this provisioning / install script, but it can be used on its own.

How to
The script should go in non-public, secure directory, which is somewhere below the site doc root. I haven't tried running it with permissions less than sudo, though it may be possible. Invoke by doing:

sh path/to/dump_and_checkin.sh

It has logging and verbose output for confirmation of it's operations on the command line.

Future possiblities includes doing something like this to cut down on the size of the diffs committed, but since haven't gotten a chance to test that in a prodcution environment, am sticking with with plain-and-simple in order to guarantee integrity of the SQL file.

Download
dump_commit.sh.zip

dump_commit_w_perms.sh.zip (dump and commit, plus update file permissions, a feature not related to backup - simply for maintenance reasons. I use this one myself, but use the other script if this feature is not wanted or needed)

The Drupal forum.module has become, well, somewhat infamous for less than awesome scalability. Recently I had a chance to see this firsthand, and track down a solution for managing the long page load times for a client who has a highly trafficked forum. This was not a case of a site that was un-tuned - actually this particular site had a lot of good work and performance enhancements already done to it, including block caching and even some modifications to the forum module that were allowing to work better than it would have without them. But still 5-6 second page load times on /forum persisted.

As this was my first time working on the site, I began by reviewing all of the main configuration files for Apache, MySQL, and PHP, since they are the foundation for everything else. After making some adjustment there, I headed over to the Drupal admin interface and check /admin/setting/performance/ and made sure all was happy there as well. Finally, I went to the block admin page and double-checked all of the blockcache settings, which as it turns out were set a bit to aggressively, resulting in slow form submission times (every time anyone submitted anything a gazillion blocks were being re-cached whether they need to be or not).

With the foundation of the site now looking good and everything, except the forum pages flying along (and the tracker, but that's a story for a later article) - it was just down to forum.module.

It's been a couple weeks since we posted part one of our look at optimizing a Drupal site to withstand large amounts of traffic,
and since that time it happened again - a site we host, got "Farked" (an inbound link from Fark.com) even bigger than it did last time. In the 8 short hours since the link to the client's site went up, and as I write this - the site has received 27,000 + unique viewers. When I logged in there to the site there actually were 1850 users online at the same time.

We just about fell out of our chair when we saw that...

...after all this is a site is that's on a shared server - not a dedicated one. And those kind of numbers would even give some dedicated servers a thorough workout. In the meantime, it was operation 911. Forget the long term issue of finding a larger server space for this site which clearly is outgrowing it's enviroment - that could be handled afterwards. Right now, we had to get the server and site back pronto.

(This article is made specifically for showing how to get raw content into Drupal, but the methods below can likely be adapted for other use cases [we also imported a list of users using these techniques for instance].)

Importing raw content into Drupal, can be, well let's just say it's not always easy. In two years of experience with Drupal we've imported a MoveableType site, a Blogspot site, content from one Drupal site to the other, and now raw data from a csv file (raw meaning that it did not come from some other CMS/website), and we've used everything from custom scripts, several different Drupal modules along the way including import-exportapi.module, userimport.module, nodeimport.module, WordPresstoDrupal.module.With the exception of the WordPresstoDrupal.module we've been mostly disappointed with the results of our experiments with the Drupal based import options. That said, this may not be the best method to start off with if you can find a ready-made solution that works for you, since it is somewhat time consuming.

Besides being a somewhat complex thing to begin with, the issues around importing content into a Drupal installation are exacerbated by the wide array of variables any point and click solution has to contend with. It's impossible for any module developer to be able to keep up with the number of different/custom Drupal content types for even one version of Drupal, let alone for all new versions of Drupal.