Blog

A couple days ago, when building a quick site with limited functionality (basically a pretty front end to a database website), I ran into a hiccup with my custom module/theme for the site, which caused me to scratch my head for a few minutes.

In my custom module (called 'idcards'), I added a stylesheet for a couple forms on the site using the drupal_add_css() function:

/**
 * Implementation of drupal_add_css()
 */
drupal_add_css(drupal_get_path('module', 'idcards') .'/idcards.css');

Later on in the development, I added a custom theme (based off a Zen subtheme I use for many smaller sites), and in that custom theme's .info file, I added a stylesheet named idcards.css.

When I cleared all the caches, I noticed the custom form styling (added by the module's idcards.css file) was missing, and on further investigation, I found that the module's idcards.css file was not being added to the pages!

With less than two weeks remaining until Drupal 7's 'code freeze,' when new features and major patches will no longer be added to Drupal 7 (instead, everyone will work to optimize and clean up all the approved patches/features for an official Drupal 7 release), it's crunch time for those wishing to make Drupal a dream for designers and themers.

Initially, I had a lot of time to help along with a bunch of other great Drupal users (new and veteran alike) to help nail down a better set of core template files (.tpl.php files), along with some CSS definitions, in order to allow people to code new (and hopefully better) themes straight from Drupal core, using nothing but CSS and a .info file. (See the Stark theme (built into Drupal 7) for an example of how simple a Drupal theme can truly be!).

We've made it through:

I will never fly United Airlines again.

I am a very patient kind of person (at least I think so), and I am typically one to let things slide unless they're pretty radically against the grain. But today, even after giving United three opportunities to redeem their 'United Express' service, I have decided to not acquire any of their services again.

First: I didn't expect much from them, as they are a very 'economical' choice in terms of price/amenities. But I did expect to be relatively comfortable (at least as comfortable as sitting in a subway seat for a few hours, and relatively on-time. The first flight from JFK to IAD was delayed almost 45 minutes, during which time a full flight had to sit in an un-airconditioned/non-working airplane. This was quite annoying, but I thought, "Well, it ain't so bad: you still have your wits about you." Then I realized we were sitting on a plane with a broken secondary engine, probably bought from some junkyard and refitted with used seats and an inexperienced flight crew, and my life was in jeopardy.

I just discovered (after asking about it in the #drupal IRC channel) the wonderful little program ab, included in an Apache installation. This little nugget does one thing, and does it well: It beats the heck out of your server, then tells you how your server did in terms of page serving. I tested a few different configurations on a dedicated, 4-core, 4 GB RAM server from SoftLayer, and used the following two commands:

1. Download the specified URL 1,000 times, with KeepAlive turned off (each request gets a new http connection):

ab -n 1000 -c 5 http://ip.address.of.site/path-to-page.php

2. Downlaod the specified URL 1,000 times, with KeepAlive turned on (thus allowing the connection to be maintained for as many http downloads as you have set in your httpd.conf file):

ab -n 1000 -kc 5 http://ip.address.of.site/path-to-page.php

I ran these tests a few different ways, and here are the results of the tests I ran with KeepAlive on, with the number of pages per second ab reported listed after the method:

• Drupal - normal page caching turned on, css/js aggregation, 55kb page – 12.5 pages/sec
• Joomla - no page caching (disabled due to buggy 1.x caching), 65kb page – 8.2 pages/sec
• Drupal - boost module enabled, serving up the boost-cached file – 3,250 pages/sec
• Joomla - custom page caching system enabled, serving static html file – 2,600 pages/sec

Speed boost due to caching: ~250x faster!

Initially, when thinking about finally taking the plunge and purchasing a slice or two from Slicehost, I thought, "wow, this is going to be incredibly fast and awesome, compared to my Host Gator account!"

But, after setting everything up and putting Open Source Catholic live on the fresh slice, running free -m, and looking at the results, reality set in: 256 MB of RAM is not much to work with if you're running a Drupal site on a LAMP stack! Drupal usually consumes 15-40 MB of RAM per page view for a logged-in user, and if you have a site with 10 or so logged in users at any moment... well, bad things can happen.

For anonymous users, using Boost will help your site fly no matter the amount of RAM you have. But even so, a bunch of requests to uncached pages will cause your site to load a heck of a lot slower, and will fill up your RAM faster than a fire hose fills up an 8 oz. glass!

Using default Apache, MySQL and PHP settings, free -m showed a full 250 MB of RAM used, along with 400-500 swap space used (swap should be kept to a minimum—if you have a lot of swap usage, that means the hard drive is being used instead of RAM, and the hard drive is inherently many times slower!). After performing a few quick modifications to Apache and MySQL, I was able to get this number down to 140 MB RAM / 40-60 MB swap, on average.

I modified the server configuration in two different places: Apache's httpd.conf, and MySQL's my.cnf: