Apache httpd is full of features and abilities, but sometimes it’s too heavy for simple sites or static pages. In some cases, a simpler, lighter web server is a good alternative (or addition). Julio M. Merino Vidal demonstrates how to install and configure the simple, fast, and powerful thttpd to serve simple static and generated content very quickly.
Lightweight Web Serving with thttpd (and NetBSD)
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Had been looking for a quick and simple guide to how to set this up. Good piece, thanks.
Very cool article, minimal solutions are great! They’re both functional *and* aesthetically pleasant.
I was considering something like that for my home server, but actually I was thinking of lighttpd as web server – while keeping NetBSD as the OS choice.
Anyway, from what I’m reading, the choice among Apache, thttpd and lighttpd purely depends on the scenario, since each one of them has its strong points (it sounds like commonplace, but if you search the net for use cases and benchmarks it’s exactly like that).
Edited 2005-11-11 10:42
It’s a 250KB download (from http://www.aprelium.com/), and it’s a fully featured web-server (including CGI, SSI, authorised domains and more) which has a really easy to use GUI.
The X2 version (with virtual server support among other things) is commerical, but the X1 version is free, and available for Windows and Linux. It’s a great solution if you’re developing a web-app, you can even install it into your home folder. Personally, I find I lose a day every time I have to set up Apache for a new project, it’s an incredibly involved task. With Abyss you can get going in minutes.
With regard to the article, I’d be wary of using thttpd alongside Apache, I’m sure Apache has enough profiling built in to optimise the static case where necessary, and I’m not sure something tiny like thttpd has the code necessary to balance requests during high hit-rate periods. I think the original options: embedded systems; old systems; and large systems that have limited internal uses are better use-cases
Yep it sure is !!! I’ve been using it for ages
I currently use Abyss and thttpd. It’s nice to know that someone here likes Abyss. ^_^
I’ve also had very good experience with abyss web server.
Recently i have thougt about setting up ligtHTTPd on my newly intalled ubuntu server though. It looks very promising.
Smallest webserver ever.
It’s a shell script. Very nice – and very educational too!
http://blog.onetbsd.de/?p=33#more-33
Indeed! I’ve a copy of this script myself. VERY educational.
Another good small server is WEBrick, part of Ruby.
why do people seek “lightweight” webservers????
apache, even loaded up with optional modules, and even with so-so hardware, can easily saturate the outbound connection most colocations provide you (typically 100base t)
you can’t push out more data than that little wire can carry kids, sorry. this is why in-kernel webserving has been a dead-end. this is why none of the major high-traffic sites bother with serioous commitments to alternative serving platforms.
How many bits you can push is not usually the main issues these days — how much memory and CPU you eat pushing those bits is the big deal. Smaller webservers such as thttpd and lighttpd can be vastly more efficent at servicing lots of concurrent connections (in the 1000+ range) using small amounts of memory and CPU time. Here, for example, is a nice article on how lighttpd handles being Slashdotted vs. how Apache handles it:
http://weblog.textdrive.com/article/44/taking-a-full-frontal-slashd…
you handle “slashdotting” with akamai and load balancing, which also provides fault tolerance and geospatial failover.
if you are in business serving content, you already know this, and you are likely serving off of boxes with 2gb+
now this isn’t to say its desirable to use more resources, but apache isn’t just frittering that memory away – its using it to deliver features most web content developers want.
Your last statement (about Apache not frittering away resources) does not make sense in light of the Textdrive example I posted earlier — both Web servers fully supported the features the job required, but Lighttpd did the job in this case with a quarter the memory and (probably) a fiftieth to a twentieth of the slots in the process table. I am not in the hosting biz, but to me that would translate directly into hosting more sites per box as well as having more boxes available for failover for the same $$$.
Edited 2005-11-12 01:07
>> I am not in the hosting biz, but to me that would
>> translate directly into hosting more sites per box
but your users are going to want php, mod_perl, mysql connectivity, java support, etc etc etc
once again, this brings you back to apache.
Maybe you could read the article.
Though you may make a good point, the idea behind light weight web servers to get some use of that used bitty box. Apache is a truely awesome web server, period. It is however a bit large to run along side lots of other services and daemons like samba, nfs, mysql etc. that one may want to run on a home server.
For me, had I continued running my old web/file/print/db/folding/etc server (p3 400mhz 384mb ram) I would’ve switched to lighter more elegant solution instead. For me it’s not the data throughput (though I’m not sure, I’d bet apache has better performance than the others) it’s the lesser amount of resources consumed.
“apache, even loaded up with optional modules, and even with so-so hardware, can easily saturate the outbound connection most colocations provide you (typically 100base t) ”
You’re statement is simply wrong. It depends on many factors. One factor is the size of each request. If the file size is small, you won’t saturate a 100mbit/s link with Apache httpd. Furthermore, we live in the age of Gigabit links.
Try it yourself and do some measurements using realistic traffic and compare. Personally, I recommend lighttpd for free(!) high performance webserving, because it gives you some great options when using FastCGI.
first, i am talking about the average request size. if all you are serving is lots of small images, once again you should be using an edge cache like akamai.
how many colos provide gigbit connections to each server in each rack? my understanding is that this is still the exception, not the rule. if you can afford that connection you likely have need of real features and have the hardware to handle it, and you are almost certainly using apache already.
forsaking the huge developer community for apache, the wealth of modules and support, and the benefit of more eyeballs in general just for a 1% increase in efficiency is just stupid.
once again if you are just serving little images, you should be edge caching.
Actually, apache is pretty inefficient when it comes to doing things like serving just graphics. Something like thttpd or boa as an images server…and letting apache handle the dynamic pages works pretty darn well.
As an aside, I’ve had some problems with Apache 2 on NetBSD 2.x, too. The prefork module has some problems with the scheduler it seems resulting in long IO waits for each process. Using the worker mpm works much better, but performance still didn’t seem up-to-par when I gave up on it (just changed jobs). Reading through, it appears that this bug is known, and exists on Darwin, too.
My experience tells me that Apache is not a very good solution to say… handle thousands of concurrent connections. The famous “slashdot effect” could be avoided by using better tolls…
>> My experience tells me that Apache is not a very good solution to say… handle thousands of concurrent connections.
then your experience is the same as most of the other posters here: nonexistant and based on conjecture or what you think is insightful.
look at the architecture for any “real” website, and i don’t mean your little blog that gets 10k hits a day and by some oddness may get a spike. i mean yahoo. i mean google.
these sites use hardware and network load balancing, edge caching, and redudancy/failover to keep serving traffic no matter what. what they want out of a webserver is features.
almost every comment here seems to think your derive performance and robustness (handle “slashdot effect”) by going lightweight on one box, which is wrong, but doesn’t surprise me.