performance

apachebench is an excellent performance and load-testing tool for any website, and Drupal-based sites are no exception. A lot of Drupal sites, though, need to be measured not only under heavy anonymous traffic load (users who aren't logged in), but also under heavy authenticated-user load.

Drupal.org has some good tips for ab testing, but the details for using ab's '-C' option (notice the capital C... C is for Cookie) are lacking. Basically, if you pass the -C option with a valid session ID/cookie, Drupal will send ab the page as if ab were authenticated.

Instead of constantly going into the database and looking up session IDs and such nonsense, I have a simple script, which is quite revised from the 2008-era script originally from 2bits that worked with Drupal 5, which will give you the proper ab commands for stress-testing your Drupal site under authenticated user load. Simply copy the attached script (source pasted below) to your site's docroot, and run the command from the command line as follows:

I currently own or use a variety of Macs, and am approaching the end of a 'cycle' of Mac usage, where I need to decided what Mac I'd like to purchase next. Currently, I'm using a 27" iMac at work, an 11" MacBook Air (from work) for travel, and a 24" iMac at home. They're all great computers in their own right, and using Dropbox, MobileMe, and a couple other helper services, I can operate simultaneously on all three Macs, without any hiccups.

So, I'm thinking about getting a new Mac for hardcore development work (web and app), some graphic design, and possible portability. I have an iPad for lighter computing (reading, browsing, email, videos...), so even though the MacBook Air is probably the best thing to happen to a laptop in a very long time, I'm shying away from it as my primary personal computer.

I've spent a lot of time working on making sure my smaller Drupal sites (mostly run on shared hosts or very small VPSes) run lean and mean. This helps the pages load faster, users are happier, and my hosting providers don't have to shut down any of my sites, even when they're under pretty heavy load.

Here are my three recommendations for making your Drupal 7 website run great on a shared (or low-end VPS) host:

I recently had a rather unique project requirement on one of my sites: I needed to send out a weekly email to hundreds (soon to be thousands) of site users, with the same template each week, but with the latest data from the website.

Basically, what I wanted to do was create a View on my site of the latest 10-12 items, and have that view be sent out to everyone (along with the views header/footer) in HTML (with a plain text alternative, of course), but I didn't want to have to create a new newsletter by hand each week to do this (this is something at which the Simplenews module excels... minus the automation).

After debating over whether I should write my own module to do the dirty work of sending out batches of emails, using modules like Views Send along with Rules and Views Bulk Operations, and some other crazy ideas, I finally found a potent combination for sending out automated weekly newsletters in a highly performant and optimal way, using the following modules:

• Simplenews (for queuing/sending emails, managing subscriptions)
• Rules (for scheduling the newsletters)
• Elysia Cron (for easy cron scheduling and performance)
• Views (to build the body of the newsletter)
• Mime Mail (to send HTML emails, and to be able to easily have a custom email-friendly stylesheet)

Recently, I was troubleshooting performance issues on a few different websites, and was stymied by the fact that YSlow repeatedly reported an F for "Compress components with gzip," even though online sites like GIDNetwork's Gzip test were reporting successful Gzipping of text components on the site.

Yslow results - not very happy.

After scratching my head for a while, I finally figured out the problem, hinted at by a comment on a question on Stack Overflow. Our work's proxy server was blocking the 'Accept-Encoding' http header that is sent along with every file request; this prevented a gzipped transfer of any file, thus Yslow gave an F.

I set up a secure tunnel (using SSH) from my computer to the web server directly, and then reloaded the page in FireFox, and re-ran YSlow:

I posted a story over on Open Source Catholic today concerning page caching and its importance for saving a server under a heavy load (read: the slashdot effect). You can save a lot of resources on your server by not only using built-in page caching on your favorite CMS, but also exploring further options (for Drupal, there's Boost (read our case study on Boost); for WordPress, there's WP Super Cache). From OSC:

A couple months ago, the Archdiocese of Saint Louis announced that a new Archbishop had been chosen (then-Archbishop-elect Robert J. Carlson). For the announcement, the Archdiocese streamed the press conference online, then posted pictures on the St. Louis Review website of the day's events (updated every hour or two).

To the uninitiated, Boost is a module for Drupal which has the potential to make your Drupal-based website run many times faster than it's currently running. Boost basically converts pages on a Drupal site into static html files, and allows your website to direct anonymous (non-logged-in) users to the cached html pages.

Doing so speeds your site up quite a bit, because instead of your web server having to run some PHP scripts and connect to your website's database, the server can simply send the complete html file, which requires no extra processor cycles or memory to compile. If your website has a lot of anonymous traffic, the potential speedup is very large. Instead of serving hundreds of users per minute, you could serve thousands.