apache

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:

Much happier now. I've contacted our IT department to see if it's possible to allow the proxy server to pass through the Accept-Encoding headers, but for now, I'll know to watch out for false positives on the YSlow test, and check from multiple locations.

I've begun working a lot more with Drupal multisites, as doing so saves a lot of time in certain situations (usually, when you have a large group of sites that use the same kinds of Drupal modules, but need to have separate databases and front-end information.

One problem I've finally overcome is the use of actual domain host names for development (i.e. typing in dev.example.com instead of localhost to get to a site). This is important when doing multisite work, as it lets you use Drupal's built-in multisite capabilities without having to hack your way around using the http://localhost/ url.

Here's what I did to use dev.example.com to access a dev.example.com multisite in a Drupal installation using MAMP (the dev.example.com folder is located within Drupal's /sites/ folder):

1. Edit MAMP/Apache's httpd.conf file - it's located at /Applications/MAMP/conf/apache/httpd.conf
   1. Put in the following at the end of the file:
      

      <virtualhost>
        DocumentRoot /Applications/MAMP/htdocs
        ServerName dev.example.com
      </virtualhost>

2. Restart Apache (in MAMP, click stop servers, then start servers).
3. Open up Terminal (in Applications > Utilities), and type in $ sudo nano /private/etc/hosts
   1. Type in your password if requested
4. In the hosts file, add a new line after the line that reads 127.0.0.1         localhost:
   • 127.0.0.1         dev.example.com
5. Save the file by pressing Control+O (this writes the file) and then Return when it says 'File Name to Write:', then press Control+X to exit nano.
6. Now, flush Mac OS X's DNS cache by typing:
   • sudo dscacheutil -flushcache

Now, if you are behind a proxy server (i.e. if you have the Network settings in System Preferences set to use a proxy server for Web traffic), you will need to also add your dev.example.com entry to the 'Bypass proxies for these domains' field (localhost/127.0.0.1 should already be present here).

Next time you visit http://dev.example.com/ in your web browser, Drupal should point you to the appropriate multisite folder on your local Mac!

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:

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).

During this period of time, the Archdiocesan website had over 2,000 visitors per hour, and almost all the visitors were hitting the home page. The website (run on Joomla 1.0.x) didn't have many caching mechanisms in place, and for almost a complete hour, the website was returning server errors as the processor was pegged at 100% utilization. Something had to be done!

Continue reading on Open Source Catholic »