Posted: Feb 8, 2011
By: Dhwanit | 0 comments
Category: Apps

amazon, apache, aws, lighttpd, performance

HomeBlogperformance → Apache (httpd) and lighttpd on an Amazon AWS Basic AMI
From our Design blog

How we built the Horlicks WizKids website

Horlicks WizKids is South Asia's largest interschool fiesta with over 200,000 children...

HTML and CSS tricks for good website design

Even the most experienced and best CSS/HTML designer out there does not have the vast myriad sets...

HTML 5: The future of rich-media web

In the ever-changing world of the web, its surprising to see how long HTML 4.x has held on to its...

From our Apps blog

Calculate your Amazon AWS Hosting Costs using Excel

One of the most common questions that come up whenever we recommend Amazon AWS as a hosting...

Drupal in the Amazon AWS Cloud

Recently, we worked on and delivered a user voting web application, hosted on the Amazon Web...

Apache (httpd) and lighttpd on an Amazon AWS Basic AMI

Over the last couple of days we did some intensive work on comparing execution of a complex...

Apache (httpd) and lighttpd on an Amazon AWS Basic AMI

Over the last couple of days we did some intensive work on comparing execution of a complex business process management web application, developed using Drupal and CakePHP, by alternating its run on Apache first and then on lighttpd. The need of the hour was optimization without touching the application software itself (which will come up later).

After having gone through a whole bunch of online resources and comparisons, it seemed justified for us to host our application on lighttpd as the way to move forward. According to all the expert views, lighttpd is fast, can handle thousands of concurrent requests without barfing or occupying huge amounts of memory and it doesn't use processes per connection thus relieving the OS to do more important things, like fetching network traffic or managing disks.

Most comparisons we came across were done on localhost or over the local LAN with crazy throughputs and mind boggling number of requests per second handled, which were impressive to look at, but definitely did not depict a real-world situation that we'd be dealing with once our application goes live. So, we had to come up with our own numbers with the software running on a server on the Internet being accessed over slow broadband connections in India (which defines 90% of our target market).

Server configuration

We've been test driving Amazon Web Services over the past few months (ever since they came up with the Amazon AWS free usage tier) on a 32-bit micro-instance running a basic Amazon Machine Instance (AMI in Amazon-speak). Simply put, its a 32-bit installation of Linux 2.6.34. The rest of the configuration: 613MB of RAM, up-to 2 EC2 compute units, 10GB of persistent storage on EBS. Amazon micro-instances provide a small amount of consistent CPU resources and allow you to burst CPU capacity when additional cycles are available. They are well suited for lower throughput applications that consume significant compute cycles periodically.

Installing lighttpd

Amazon's repository includes a pre-built version of lighttpd version 1.4.28 (latest release as of Feb 2011), so that's where we began. Installation was straight-forward:

yum -y install lighttpd
yum -y install lighttpd-fastcgi

While starting up lighttpd after this was no problem, it showed us the static welcome page when we visited the newly set up server. Making this work with our web application, based on Drupal and CakePHP was a bit involved. We were initially thrown off guard when yum created a fastcgi.conf file that looked a bit strange compared to numerous examples on the net. But eventually, we settled on not uncommenting any of the examples provided in the file, instead we added the following configuration:

File: /etc/lighttpd/conf.d/fastcgi.conf

fastcgi.server = ( ".php" =>
                       "socket" => "/tmp/php-fastcgi-1.socket",
                       "bin-path" => "/usr/bin/php-cgi",
                       "max-procs" => 1,
                       "broken-scriptfilename" => "enable",

We also uncommented out mod_rewrite in the list of standard modules along with uncommenting lines that included the conf files for magnet and fastcgi, all in the same file:

File: /etc/lighttpd/modules.conf

server.modules = (
#  "mod_alias",
#  "mod_auth",
#  "mod_evasive",
#  "mod_redirect",
#  "mod_setenv",
#  "mod_usertrack",

# many more lines here...

include "conf.d/magnet.conf"
include "conf.d/fastcgi.conf"

In order to make pretty URLs and Apache equivalent redirects to work with the Drupal component of our application, we copied over Albright's Ultimate Lua script into our /var/www area and set it up:

File: /etc/lighttpd/conf.d/magnet.conf

magnet.attract-physical-path-to = ("/var/www/drupal.lua" )

This gave us a baseline installation of lighttpd that was compatible with Drupal and CakePHP.

Compressed output

The first issue, for our application, was that lighttpd was not compressing HTML output being sent to the browser. After a quick search it became clear that mod_compress was not going to do the trick for us since it works only on static HTML files. What we needed was mod_deflate, which wasn't readily available as part of any lighttpd 1.4.x release candidates (its planned as part of lighttpd 1.5). So, we had to build lighttpd 1.4.28 from source after patching in the required changes to enable mod_deflate that compresses dynamically generated HTML when being sent to the browser. The official mod_deflate wiki documentation does not list a patch for 1.4.28, however with minor modifications, the patch file for 1.4.26 worked on version 1.4.28. We've created a patch file for lighttpd 1.4.28 that enables mod_deflate which you can download here: lighttpd-1.4.28.mod_deflate.patch.

Build instructions

Grab the release tarball of lighttpd 1.4.28 from the official downloads page and apply the patch after extracting the tarball:

patch -p0 < lighttpd-1.4.28.mod_deflate.patch

Run the configuration script from your lighttpd-1.4.28 directory. We needed to have SSL and memcache enabled, so we used the following command, all in one line (assumes that all the -devel libraries have been installed for mysql, php, openssl, gamin, zlib, bzip2, lua, memcached. Also assumes libmemcache has been built previously).

./configure --prefix=/lighty_custom --with-mysql --with-zlib
            --with-bzip2 --with-fam --with-memcache --with-lua
            --with-openssl --with-gdbm

Build lighttpd from your lighttpd-1.4.28 directory:

make install

This will set up your custom version of lighttpd in /lighty_custom. To make this custom version of lighttpd work using the "service" command, make the following changes:

File: /etc/init.d/lighttpd


Configure mod_deflate. Create a new file in your lighttpd conf.d directory:

File: /etc/lighttpd/conf.d/deflate.conf

server.modules += ( "mod_deflate" )

deflate.enabled = "enable" 
deflate.compression-level = 9
deflate.mem-level = 9
deflate.window-size = 15
deflate.bzip2 = "enable" 
deflate.min-compress-size = 200
deflate.work-block-size = 512
deflate.mimetypes = ("text/html", "text/plain", "text/css", "text/javascript", "text/xml")

Include the deflate.conf in the list of modules being loaded:

File: /etc/lighttpd/modules.conf

include "conf.d/deflate.conf"

Restart the lighttpd service. You should now see lighttpd compressing HTML output on dynamically generated pages from PHP.

So, what about the results?

While it took us several hours spread over a couple of days in figuring out how to set up an optimal lighttpd installation specific to our application, the benchmarking results were mixed. The first result was discouraging. Just browsing around in our application running on lighttpd seemed slower than earlier, when it was being hosted on Apache. Now 90% of the time, this can be attributed to a slow 512kbps broadband connection we have. Thus instead of relying on human experience, we used Apache Bench (ab) to run a simple benchmark test for us. This result too was discouraging.

The "ab" command we used for testing lighttpd (and Apache) without a compression enabled request (cookies to indicate logged in user):

$ ab -n 5 -C SESS39166d130128e59d9c9fa0b10f5052a6=nsjf0....
           -C SESS533bfe3264360767532928302a142586=mmhkp....

The "ab" command we used for testing lighttpd (and Apache) with a compression enabled request (cookies to indicate logged in user):

$ ab -n 5 -C SESS39166d130128e59d9c9fa0b10f5052a6=nsjf0....
          -C SESS533bfe3264360767532928302a142586=mmhkp....
          -H 'Accept-Encoding: gzip'

While I know that 5 non-concurrent hits to a server hardly constitutes a test, higher numbers just failed with lighttpd. Even 10 non-concurrent requests failed with a timeout, so the usual suspect is our local broadband connection. We have to run this test on a reliable Internet connection that doesn't fail mid-way through a test with something like a 100 or even a 1000 runs one after the other. The other issue is the Amazon micro-instance is geared towards bursty utilization of CPU resources. With "ab" its one hit after another which sure ain't bursty. An AWS micro-instance doesn't like that very much! This results in CPU throttling thus timing out some executions mid-way.

A more accurate test would be to have a fat pipe to the Internet that can sustain continuous "ab" testing over a long periods of time, and to run our application on an Amazon AWS small-instance that provides a constant amount of computing power available to the application, instead of throttling when bursty.

Final disclaimer: Take these results with a pinch of salt! :)

  lighttpd 1.4.28 Apache 2.2.16
  (no compression) (with compression) (no compression) (with compression)
Document Length 86863 86863* 86863 11247
SSL/TLS Protocol TLSv1/SSLv3,AES256-SHA,2048,256 TLSv1/SSLv3,DHE-RSA-AES256-SHA,2048,256
Test Time (seconds) 49.166 32.130 26.344 22.578
Request/Second 0.10 0.16 0.19 0.22

* Command line argument -H 'Accept-Encoding: gzip' didn't seem to have an effect on compressed output, although we could tweak compression levels and watch it in Firefox/Firebug.


Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <p> <h2> <img>
  • Lines and paragraphs break automatically.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Enter the characters shown in the image.

We're a company of experts!

Not only do we work on the design front, ensuring a great visual appeal for your visitors, we back it up by awesome software running behind the scenes virtualizing your business intelligence. We will work to give you the best!