Dashboard
Activity Stream
Audio Library
Blog
Discussions Board
Event Calendar
File Repository
Image Gallery
Status Log
Video Library
Wiki
Home
cyn.in Help
Cyn.in license
Enterprise Support
Supported Browsers
Web Links
cyn.in Homepage
Cynapse Homepage
Cynapse Community
Bookmark
Why Apache as a front end?
Probably the first and most important question to answer is WHY it is so important to have Apache HTTPd as a front-end for a website.
I believe that for anyone, there's nothing more annoying than hitting a web page, waiting for a few seconds, and then seeing our favorite browser coming up with The connection was refused when attempting to contact http://www.domain.tld/
In my opinion (and my boss') it is unacceptable to have a "downtime" on a website, and if that happens, whoever connects needs to know what's going on, or, at least, we need to tell him something ... {{{We are sorry, but currently http://www.domain.tld/ is unavailable because of essential system upgrades. We expect to resume all our services in less than 10 minutes. Please, check back later}}} ... sounds so much better (maybe with our little nice logo, and yada yada, yada).
When once I asked to Brian Behlendorf why Apache was doing some oddities in the code, he responded "Call it defensive programming": this explains the entire vision behind Apache: Apache, no matter what, can not "go down" and not respond to HTTP requests. This is the essence behind it and its design is centered around this idea, so, in my opinion (and experience) it is that one option allowing us to achieve our goal of "zero port 80 downtime".
Apache's design enforces a multi-process model: there is always a minimal wrapper bound to port 80 (as safe and minimal as possible), spawning new OS processes per request doing the work. This allows that even in the worst case scenario (a segmentation violation in the code that dumps the entire OS process), something will be sent back to the client.
A Java-based web server can not achieve this. Java is a single-process environment and if something happens to it, it will just exit, unbinding port 80 and leaving our clients with "connection refused".
I believe that for anyone, there's nothing more annoying than hitting a web page, waiting for a few seconds, and then seeing our favorite browser coming up with The connection was refused when attempting to contact http://www.domain.tld/
In my opinion (and my boss') it is unacceptable to have a "downtime" on a website, and if that happens, whoever connects needs to know what's going on, or, at least, we need to tell him something ... {{{We are sorry, but currently http://www.domain.tld/ is unavailable because of essential system upgrades. We expect to resume all our services in less than 10 minutes. Please, check back later}}} ... sounds so much better (maybe with our little nice logo, and yada yada, yada).
When once I asked to Brian Behlendorf why Apache was doing some oddities in the code, he responded "Call it defensive programming": this explains the entire vision behind Apache: Apache, no matter what, can not "go down" and not respond to HTTP requests. This is the essence behind it and its design is centered around this idea, so, in my opinion (and experience) it is that one option allowing us to achieve our goal of "zero port 80 downtime".
Apache's design enforces a multi-process model: there is always a minimal wrapper bound to port 80 (as safe and minimal as possible), spawning new OS processes per request doing the work. This allows that even in the worst case scenario (a segmentation violation in the code that dumps the entire OS process), something will be sent back to the client.
A Java-based web server can not achieve this. Java is a single-process environment and if something happens to it, it will just exit, unbinding port 80 and leaving our clients with "connection refused".
The performance benchmarks are here: http://www.cherokee-project.com/benchmarks.html
There's also the essential (for Cyn.in needs) reverse proxy module: http://www.cherokee-project.com/[…]/modules_handlers_proxy.html
Do let us know if you do manage to get it working or if you need help with the rewrite rules, etc. There's nothing quite like a real-life test, where you can "feel" the difference, is there? :)
The other advantage that Apache offers is the wide breadth of battle-tested modules and peripheral products like log analyzers and whatever-else that are out there, ready-to-use. For an example, it's very easily possible to pick up existing modules and cobble together a simple Single Sign On with Cyn.in and still have a setup that is pretty solid. Flexibility is paramount, at least for the default Cyn.in deployment strategy, but having alternatives like Cherokee that have been purpose-built with speed in mind is always going to be a good thing, especially for those special-requirement setups.
Personally, I'm a bit curious on the need aspect of this question of yous. Surely, you'll find that you hit optimization+caching requirements in Cyn.in/Plone much, much before you can reach a point of differentiation between front-ending web servers, IMHO. Or are you looking at a minimizing resource requirements? Is there a particular need that is causing you to look away from Apache? Do tell.