Craig Strong

My main personal web servers run using Fedora and to date I have had no real problems and very reliable performance from this great Linux distribution. I generally stick the RH based distributions for familiarity reasons. Recently though I was setting up my development VM and I thought I’d try something a little different. I was looking for something with a much smaller footprint and something which is obviously simple and very secure and something which is not too far away from my Linux habits. Having done some extensive reading, OpenBSD seemed to stand out as one closer to my preferences. Light, simple and very secure with good documentation and support. So far I am very much enjoying the choice and think OpenBSD is firming a place in my future toolset.

Anyway setting up a web development environment is my goal my first port of call is to install Cherokee as my web server of choice. Having seen the performance benefits of this server (see other post), this was the sensible choice for me to make. I plan to install cacti, Yii Framework, PHPUnit, PHP5, XDebug and MySQL and Git as well as a few other tools to complete my development environment.

Coming from Fedora where YUM provides a great package management solution, I was pleased to see some similarities in OpenBSD with ports and pkg* tools. The documentation is good and as advised I added the packages references using my local mirror. Then I decided to choose the easy root and install cherokee 0.99 by running the following :

sudo pkg_add -v cherokee

This installed the package straight away and at the end of the install provided on screen guidance in configuring cherokee to start up on default. The follow settings are displayed :

If you want to run cherokee on boot, add these lines to /etc/rc.local:

if [ X"${cherokee_flags}" != X"NO" ]; then

echo -n ‘ cherokee’

/usr/local/sbin/cherokee ${cherokee_flags} 1> /dev/null

fi

for admin management:

if [ X"${cherokee-admin_flags}" != X"NO" ]; then

echo -n ‘ cherokee-admin’

/usr/local/sbin/cherokee-admin ${cherokee-admin_flags} 1> /dev/null &

fi

and in /etc/rc.conf.local:

cherokee_flags=”-d”     # use -d to run in daemon mode

cherokee-admin_flags=NO # use -b if you want listen on ALL interfaces

After installing this, all seemed well and I followed the Cherokee installation guidelines by running the cherokee admin tool :

/usr/local/sbin/cherokee-admin – -bind 192.168.0.20 – -port 8080

This then presented with me with the relevant username and password settings to logging to cherokee admin. Using these details I tried logging into the admin section by going to :

bsdvm:8080

bsdvm is mapped to 192.168.0.20 in my hosts file (Both on my desktop machine and on my VM running openBSD).

On logging into the server I was presented with the following error :

“503 service unavailable”

The authentication seemed to work, so I was a little confused why this was happening. To debug the problem I run the command :

/usr/local/sbin/cherokee-admin –bind 192.168.0.20 –port 8080 –debug

Having run this command and trying to login again, the debug error messages were screaming about me not having python installed! I presumed that as I installed a package, python would have been included as one of the dependencies ? Obviously not and I remember having a similar problem when installing cherokee on Fedora a while back. Anyway I quickly solved the problem by installing the following :

pkg_add python-2.5.4p3.tgz

I then fired up cherokee-admin as above, and logged in without fail. Now it seems to be all running fine and I have setup my configuration settings on cherokee as I like them and my environment is running well.

As I have been developing for the web for over a decade, I have become comfortable with tools and technologies which have helped me get the job done. Some of these technologies I have seen evolve and progress into what are now essential and very powerful solutions. I have established an affinity with many of these tools and without doubt the Apache web server qualifies as such a technology for me.

Using Apache over the years as my main web server, I have produced all types of software solutions for many diverse businesses within many different industries.  Apache has served me well and I am an advocate of the old saying ‘If it’s not broken, why fix it’ (within reason). Until recently that is….

Over the past few years in the distant background I have heard mention of Cherokee as being a viable alternative to Apache, with some claiming it offers benefits. These have been whispers registering in the distance, but didn’t sound interesting enough to pursue and invest my time as Apache was doing it’s job well. However recently these whispers became a little louder following a few conversations with a work colleague singing Cherokee’s praises. What caught my attention most from the conversations wasn’t simply that Cherokee was faster, but that Cherokee was much easier to use and quicker to configure. As I don’t like ‘shaving Yaks‘, my approach was that if I start hitting obstacles, I’ll leave it for another day which contains more than 24 hours; after all Apache is working well for me.

My local lightweight development environment consists of a Linux VM (Fedora) which I operate using VirtualBox. I deliberately reduce my VM’s resource allocation such as setting my RAM allocation to 512mb on my VM to encourage good code and to identify memory leaks. I have the other usual stuff setup such as Zend Framework, xdebug, MySQL etc. This was the machine which was going to carry out the test switch from my trusted Apache to Cherokee.

I disabled Apache and installed Cherokee using the supporting well written user guide. Within minutes Cherokee was up and running and there we NO problems! I was expecting some configuration hurdles as per usual, but nothing. My sites were running as if I was on Apache and there were no noticeable differences. I configured the logs to act as the same as Apache and all was set.

As I delved deeper into the setup guide I was pleasantly introduced to Cherokee’s administration interface. This was a pleasant surprise as I’m so used to hard coding configuration information into httpd.conf. This interface presents configuration options for all the usual server settings such as ‘Virtual Servers’, ‘Directory Sources’, ‘Logging’, ‘Security’ etc. The beauty of this is not that it’s simply a little prettier than the command prompt, but it’s quicker to use. You can configure your server settings simply and quickly which are two good properties to have on your side.

Although I was impressed so far, the remaining challenge that Cherokee must live up to for me is it’s speed advantages. In the spirit of keeping things simple and to get a loose overview on performance advantages I thought I’d simply use ‘Zend Controller’ which is bundled with ‘Zend Server CE‘ to test how many requests per second both Apache and Cherokee could handle in turn upon my humble local virtual machine. From these tests I obtained the following results :

Apache Web Server Results

Apache requests per second on local VM

Cherokee Web Server Results

Cherokee requests per second on local VM

As you can imagine I was quite impressed with what the results presented. The results roughly show that Cherokee could handle 2.5 times more requests per second that Apache! That is no small margin!

What does this mean for me going forward? Well the first things that went through my mind understandably were cost and time savings. Potentially this could reduce the need for more hardware. Less hardware means less purchase costs and less maintenance time. Obviously there are other factors to consider before jumping the gun, but Cherokee certainly has my attention now. I will definitely be including Cherokee in my future plans. An exercise well worth the time.

If anyone reading this has done the switch, please feel free to reply to this post with any feedback

Related Link : alobbs.com