Tag: cherokee

What a difference two years make

A little over two years ago, I wrote “a post”:/2009/01/26/web-server-software-on-linux/ about my view of the web server software landscape under Linux, concluding with how I’d ended up sticking with Apache despite having tried most of the other reasonable candidates because they all seemed lacking.

It’s interesting in part because I never recorded when I moved that server from Apache to Cherokee (which I had tried to poor results, as noted in the post), which would have been not too very long after I wrote that post. Oh, well.

Anyway, everything ran alright on Cherokee for 18 months or so, but Cherokee wouldn’t let me do per-client bandwidth throttling, which I really needed as Chet’s blog was getting hammered mercilessly by spammers, and I couldn’t figure out any other way to slow them down.

So I switched to nginx, which by now I have a fair amount of experience with, using it for http and imap proxying as well as serving fastcgi apps for other projects. If it weren’t for the decrepit software that Chet and I have been using for blogging for the last couple or three years, everything would have been great (Movable Type–and even its follow-on project Open Melody–has never modernized its low-level infrastructure to allow good support of FastCGI; they’ll tell you they have, but just ask them if you can do XML-RPC–the foundation for remote posting–and watch their reaction).

Still, I’ve made do with a FastCGI shim for Movable Type, and then decided to start looking at WordPress, which I’ve already converted to, and which I think we will get Chet converted to shortly.

Incidentally, I became even happier about having moved to nginx about a week later, when I ran across a blog post from Cherokee’s author, posting a link to “a performance comparison”:http://www.alobbs.com/1390/Linux_Format_benchmarks_Cherokee.html#comments that showed Cherokee beating everything else.

Normally, I would just say “great” and move on, but knowing a little bit about nginx, I was surprised at the version being used, as it seemed a little old. And so I did some more research, and found that the article was comparing an up-to-date version of Cherokee to much older versions of other servers, in some cases versions from branches that had long been declared obsolete. Still, it’s not the fault of Cherokee’s author someone at a magazine did a crappy test.

However, when I presented my findings, and asked him to acknowledge the issue, and call for the author of the article to do better:

bq. Alvaro, I understand that it is nice to see your software perform well against its competition, but I would encourage you to dissociate yourself from this comparison, or at least take it upon yourself to point out that there were some things that may have left your competitors at a disadvantage.

he suggested that he had made any caveats he needed when he said “you shouldn’t expect an extensive, in-depth benchmark” from the “very well written article”, though he did note that “the benchmark results are still fairly representative IMHO.”, and when pressed, said that he didn’t think the results would have changed with more recent versions of the other software.

It took a while to get the taste out of my mouth. I guess I still haven’t, given that I’m posting this.

Anyway, up with nginx.

Web server software on Linux

So there has always been a multiplicity of web server software for Unix/Linux.

It certainly feels like I have, at some point or another, played with all of them. And I keep coming back to apache, which I’ve been using since 1995, when I first became responsible for running a web server (“this site”:http://www.med.miami.edu/, if you care).

Incidentally: Holy crap, 14 years.

Anyway, as I stare around the unix landscape, I see four general-purpose web servers with some mind-share: apache, lighttpd, cherokee and nginx. Yes, there are others, but they are niche players, or they are not general purpose. So here’s my issues:

h2. “lighttpd”:http://www.lighttpd.net/

For the last couple of years I’ve run wiki.mallet-assembly.org on a box that was running lighttpd. And, honestly, I’ve not really had anything to complain about; it was stable, it was fast enough, etc. But if I wanted to run fastcgi programs as some user other than www-data (better for security), I had to run them as their own daemons. This isn’t the end of the world. What ultimately made me decide against it was that lighttpd has spent much of the last two years in perpetual rewrite mode.

h2. “cherokee”:http://cherokee-project.com/

I’ve been paying attention to Cherokee for the last year or so. It was looking like an interesting alternative to lighttpd. And then I tried it. Just as was always the case with the Netscape Enterprise Server/iPlanet software that I hated when I was at Dorado, the only documented interface for configuration was web-based. This isn’t the end of the world. But when it mysteriously “broke comments”:http://mischeathen.com/2009/01/good-news-bad-news.html for no discernable reason–and we’re using straight CGI, the simplest possible option for it–that got it the boot. And it’s error log? Useless.

h2. “nginx”:http://wiki.codemongers.com/Main

Nginx is great at what it does. Seriously. Couldn’t live without it. But really, it’s a proxy that happens to have also been taught how to speak FastCGI (and IMAP and SMTP and various other things–it really is great), and as a consequence it doesn’t so some important things like, well, CGI. I am using it for wiki.mallet-assembly.org right now, because it’s ultra-light and I’m running mediawiki under FastCGI there, so it all works out, but I’m probably going to move it to apache before too long because…well, who wants to have to keep track of two different packages.

h2. “apache”:http://httpd.apache.org/

Big. Complicated, with too many options to keep track of. One of the more annoying configuration syntaxes around (Fake html tags to denote sections? Really?). But dammit, it works, even when you ask it to take care of spawning fastcgi processes as another user. And it’s not *that* baroque. And even when it is (mod_rewrite, I’m looking at _you_), it’s still better documented than any of the other options. And most of the unix-oriented web software just pretty much assumes you’re going to be using it.

There’s really just not any competition.

Now don’t get me wrong–I would be disappointed if suddenly everyone abandoned all of their other systems. An Apache monoculture would benefit no one. To those working on the other systems, well, I’m gonna keep looking at them and seeing how they evolve. If nginx sprouted *simple* CGI support (none of this “write your own FastCGI server process that would proxy the CGI scripts” stuff), I would almost certainly move to that.

But for the moment, Apache it is.