Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
The Internet Software Apache

An Overview of the Boa Web Server 185

Posted by Hemos from the smal-pretty-small dept.
Gentu writes "There is a pretty new and little known, lite web server in town, named Boa. The server can run very fast on older machines, even on embedded devices, but it is only CGI-based. OSNews introduces Boa (running under Linux) and it includes some preliminary benchmarks against Apache and thttpd."
This discussion has been archived. No new comments can be posted.

An Overview of the Boa Web Server More

An Overview of the Boa Web Server

Comments Filter:

  • Boa vs. Apache? (Score:4, Funny)

    by Anonymous Coward on Monday November 25, 2002 @09:08AM (#4750841)

    If Boa is too constricting, you might want to switch back to good ol' Apache

    Bah dum bah!

  • performance info is useless (Score:4, Insightful)

    by WPIDalamar ( 122110 ) on Monday November 25, 2002 @09:09AM (#4750848) Homepage
    The test performance against apache using a different test program for each server. Furthermore, it looks like Boa is designed for one thing... speed. Apache is designed to be feature complete. It's like comparing apples and pumpkins.

    • Re:performance info is useless (Score:3, Funny)

      by Anonymous Coward
      Nice metaphor. You can make pie out of both of them.
    • Or a mercedes S-class to a Ferrari, what you have to consider is if you want that speed. I dont really think that Boa has been designed as a competitor(not sure if this is the right word) to Apache. Time will tell it may take off you never know
    • I agree; feature-complete, Boa is not. Hasn't even hit v1.0 yet after about eight years of development.
      • As far as I know, Boa is used in embedded linux platforms...like Axis webcams, etc. I used it about three or four years ago in webcams. It provided a low-overhead means by which a browser-based configuration tool could be delivered. I think it worked great. The features are not the point. In fact, the absence of features seems to be the point.

    • Re:performance info is useless (Score:4, Insightful)

      by tmark ( 230091 ) on Monday November 25, 2002 @09:38AM (#4751056)
      It's not useless or irrelevant if you happen to be using Apache, don't need it's full feature set, and really need performance. Or maybe you're in a situation where you're considering both, and it MIGHT be convenient to use the full Apache feature set, but might be willing to work around deficiencies to have better performance. In other words, this info is relevant any time when the user is prepared to trade-off features against performance or vice-versa, when the need for feature-set and performance is not absolute and written in stone. In any such circumstance, it's entirely appropriate to compare performance, as long as the user recognizes there are other differences.
      • Or maybe you're in a situation where you're considering both, and it MIGHT be convenient to use the full Apache feature set, but might be willing to work around deficiencies to have better performance.

        Pardon me, but is sounds like you're suggesting we "use the right tool for the right job". Now I don't know if you're from k5 [kuro5hin.org] or where, but here on /., we don't do things that way.

      • ah... but they use different test apps on each, so there is no valid comparison there. If they used the same testing program on both, it might mean something.
      • I once used Boa in a situation where I couldn't get Apache to compile (an old HPUX machine). It ran a pirate web site at Oklahoma Baptist university, and used to run on http://obunix.okbu.edu:2000/ They wouldn't let us CompSci students have our own web space, so I just ran Boa in the background under my own user account, and told everyone how to set up their pages. It was fun :) I had to go and restart the darned thing every time the administrator rebooted, though (the administrator was not particularly UNIX smart - I played some minor pranks on him w/ X11 - tip to the smart - don't put the IP address of an open X server on the command line of a public system). Anyway, other CompSci students kept it up for a year or two after I left. It was kinda fun.
        • It was fun :) I had to go and restart the darned thing every time the administrator rebooted, though (the administrator was not particularly UNIX smart

          If you had to restart the webserver manually on every reboot you're not very UNIX smart either. A cron job running every 5 minutes to see if the server is still up would have taken care of it.

    • It's like comparing apples and pumpkins.

      Bad analogy, wrong use of cliche. If I was unfamiliar with pupmkins and had a professional interest in maintaining apples, I would certainly want to hear about all the special features that separate pumpkins and apples.

      I might even appreciate a comparison to lemons, even though I don't want to spend money on a Microsoft product.
    • Indeed it looks like Boa was made specifically for the efficient serving of static content, where Apache, like IIS, is made in a very versatile, full featured manner. Does this render comparisons irrelevant though? Absolutely not. The reality is that most of the content that people do serve up is static content (images, CSS files, etc), and it is entirely reasonable that a server system could include a Boa or similar hyper-optimized server specifically for the static content (i.e. http://www.static.myurl.com/css/styles.css), with the Apache or IIS server being the front line real content system. Using the right tools for the specific tasks could be very beneficial and help avoid the dreaded Slashdotting while Apache or IIS is busy serving up GB of images or static HTML files.
    • They both make delicious pies.

      Thats all that matters

  • Pretty new? (Score:5, Informative)

    by Anonymous Coward on Monday November 25, 2002 @09:10AM (#4750852)
    Pretty new? You what? I've been running it for five years. Even the OSNews article mentions that "Boa was written sometime in the early 1990's by Paul Philips". It is definitely a nice little server tho'.

  • Odd comparison? (Score:4, Interesting)

    by FreeLinux ( 555387 ) on Monday November 25, 2002 @09:12AM (#4750867)
    It seems a little odd to compare BOA and Apache. Granted Apache is the web server of choice so a comparison is not too bizarre but, it is still an apples to oranges comparison.

    Boa is much smaller than Apache. This seems like a good thing on the surface, especially for embedded applications, as was suggested in the article. But, Boa is slower and much less functional than Apache. They really aren't comparable servers.
    • Not true at all. Boa is much faster than apache on teeny hardware serving static pages. I've got it running on my own server (link in sig) and I doubt that the thing can be slashdotted easily. The pages are small, and text only for the most part.

      The bottleneck that I have is my DSL line uplink speed. My webserver can handle several connections per second, and it's only a Celery 300A with 64 megs of RAM.

  • uh (Score:5, Informative)

    by GigsVT ( 208848 ) on Monday November 25, 2002 @09:13AM (#4750870) Journal
    There is a pretty new and little known

    You'd think the submitter would at least read the article. It says right in there that it's been in development since before 1995, "In fact Boa is one of the oldest web servers in constant development".

    • Re:uh (Score:3, Interesting)

      by kaisyain ( 15013 )
      Very true. Several years ago when I was in college I ported Boa to DOS [geocities.com]. At the time I thought it was the world's first DOS httpd but was later informed someone had beaten me to the punch. At the time Corel or someone were releasing their free DOS replacement and talked to me a couple of times about including Boa for DOS but eventually their project died.

    • Re:uh (Score:2)

      by PD ( 9577 )
      Boa definitely is a nice little program. I use it on my own website (link in my sig) and have no complaints. It doesn't do a lot, but it does it well. The biggest asset that it has in my opinion is that since it's so small and built with security in mind, I can feel good about running it. It will run CGI scripts, so there's always an opportunity to break security there.

  • there are lots of options (Score:3, Informative)

    by night_flyer ( 453866 ) on Monday November 25, 2002 @09:14AM (#4750882) Homepage
    even on the windows side, there is sambar server, tiny server (which is very small and very fast), and a multitude of others, some are feature rich, others just push out plain web pages.

  • No comparisons (Score:3, Interesting)

    by mgkimsal2 ( 200677 ) on Monday November 25, 2002 @09:15AM (#4750891) Homepage
    I didn't see any benchmarks against Apache or thttpd in the article - I saw boa benchmarked with ab and zb. Looks interesting enough to try out, although I still haven't even bothered putting in thttpd to serve graphics yet, so I probably won't ever get around to boa after all. :/

  • fnord! (Score:5, Informative)

    by MisterP ( 156738 ) on Monday November 25, 2002 @09:17AM (#4750898)
    If you're interested in small webservers, fnord [www.fefe.de] is another one. It even does CGI, vhosts and directory listings and it's only 18K. It requires tcpserver though.

    • Re:fnord! (Score:3, Informative)

      by the_danielsan ( 512604 )
      URL should be http://www.fefe.de/fnord/ [www.fefe.de]

      (trailing slash)
      • URL should be http://www.fefe.de/fnord/ (trailing slash)

        That is not a very good endorsement of fnord. I'd rather use a web server that knows how to redirect "GET /foo" to "GET /foo/" transparently with http headers.

    • rws (Score:2, Informative)

      by Richard W.M. Jones ( 591125 )
      Or rws [annexia.org] which let's you use C to write CGI scripts that are loaded into the server at run time (for extreme speed), and has database access, and hence is much more useful for dynamic webpages.

      Rich.

  • "In fact, there are dozens of currently unrealized features that have already been implemented in one branch or another that might someday make it into a Boa release. In fact, there are outstanding requests for various features that have already been implemented in one of the branches that I hope will make it into the first 0.95.0 release."

    What is this all about and why do they keep saying "In fact"?

  • Still slower than ZWS (Score:5, Interesting)

    by fastlink ( 605544 ) on Monday November 25, 2002 @09:19AM (#4750917) Homepage
    Hi
    According to my tests BOA beats Apache.
    BUT the ZEUS web server (www.zeus.com [zeus.com]) which is 'feature complete' (including mod_perl in version 4.2) still beats both of them.
    Have a nice day!

  • Excellent for special UID use. (Score:5, Interesting)

    by nutcracka ( 470542 ) on Monday November 25, 2002 @09:19AM (#4750922) Homepage

    I've used Boa in a number of cases where certain groups of CGI scripts need to run as a specific UID and I didn't want to use the SUID functionality of Apache. Because it is so lightweight, having a few of these hanging around for various citical system UIDs can really be handy, esp. if you have an aversion to using SUID wrappers and such. A good example is using Boa running as the same UID as the mailing list processor so you can have web administration of the list rosters. And the users don't even know about it because I use the ProxyPass directive to shuttle the requests from the standard port 80 up to the port on which Boa is running, so my logging is still centralized/standardized through Apache.

    Boa is very cool. Kudos to the developers!

  • I'm unimpressed (Score:3, Informative)

    by Anonymous Coward on Monday November 25, 2002 @09:24AM (#4750959)
    I submited this one [nanoweb.si.kz] some weeks ago but it didn't make it to the frontpage. It's a new http server, written 100% in PHP, somebody ever tried it ?
    • Bah, PHP? Try awk [geht.net], Bash [umbc.edu] or Postscript [pugo.org] for a thrill!
    • PHP? Good grief! When did PHP suddenly become the end all be all language for writing everything? PHP is designed to make dynamic webpages and IMHO it isn't exactly the greatest at doing that. (Not a troll, good reasons for believeing that, reply if you want to know why).
      • ok, i'll bite. What's wrong with PHP?
        • offtopic but who cares I have karma to burn. Let me qualify this statement by saying that I do know and use PHP, its a part of my job. I'll also say that I know Perl and I think Perl is better so it probably makes me somewhat biased.

          Name space, name space, name space. That's what's wrong with it. I get really tired of writing function names that_seem_to_go_on_forever(). I mean come on. What is the point of array_push() why can't it just be called 'push()'? I know it works on an array!

          Interpolation. Sometimes it works sometimes it doesn't its sort of half done. I can't count how many times my PHP program has crashed because I dared to put a variable inside double quotes. The behavior appears to be almost random.

          Everything feels hacked, this goes back to the namespace issue. There is no logical way to extend PHP so new functions are just thrown into the core language. Many times they act differently than other similar functions (sorry I can't think of an example off the top of my head). Its like some people decided they wanted 'x' function and just threw it in without regard to its implementation. Things don't seem to be reused just new things thrown in. Like why can't we have a standard set of database functions where the database type you are using is declared? Nope, instead we have a whole set of mysql_* functions for MySql and another whole set of pg_* functions for Postgre.

          And finally everytime there is a new release there is some change to the core of the language. So they have to maintain cruft to be compatable and things don't break. If they would improve what they have instead of constantly adding new things this problem would go away.

          Other annoyances (mostly my opinion): Three ways to read variables from a form but still hard to make a program that can accept GET or POST method with the same variable names.

          (item1,item2,item3) is not treated as a list or an array. I can't do ($fieldname,$fieldname2) = mysql_fetch_row() ... nope I have to put them into a temporary array and set them one by one :(.

          Regexes use functions ... this is extremely annoying and there are at least two (three?) different regex sets, plus functions that duplicate what regexes can do!

          Global variables, again my opinion but I would rather declare my varibles local rather than having to declare them global. It wouldn't be so bad if I could declare my global variables once at the top of the program but no .. i have to redeclare them global in each function I'm going to use them in.

          CPAN -- for all of Perl's faults it got CPAN right. PHP needs a standard way of adding modules to its installation (so they can be used system wide) and a good place to store them. You don't know how difficult it is to write a MIME complient message in PHP.

          Finally I think PHP backwards... PHP is a language designed so that the data defines the program. Easy to slap together but difficult to maintain and very difficult to reuse code (I have to make tons of changes to the HTML page). I prefer to program so that my code defines my data. And I can give it new data to achieve new things or looks for a page or whatever ... PHP can do that its just not a simple to do as it is in other languages.

          My two cents :)
          • Ok, to continue offtopic for a couple of seconds... here is my 2c (and I'm not criticising you in *any* way, or saying you are wrong, this is _my_ experience):

            What is the point of array_push() why can't it just be called 'push()'? I know it works on an array!

            You know it works on an array because it's called array_push :-P

            Nope, instead we have a whole set of mysql_* functions for MySql and another whole set of pg_* functions for Postgre

            You can always use ADODB.

            (item1,item2,item3) is not treated as a list or an array. I can't do ($fieldname,$fieldname2) = mysql_fetch_row() ... nope I have to put them into a temporary array and set them one by one :(

            Well I've never used that syntax in *any* language! (must be a Perl thing?)

            It wouldn't be so bad if I could declare my global variables once at the top of the program but no .. i have to redeclare them global in each function I'm going to use them in.

            This is down to personal taste. I much prefer having to redeclare in each function, as it's a lot safer since you don't have to explicitly declare local variables.

            Personally, PHP does the job for me. It has its short-comings, but for small-medium size web sites you can't beat it imho.

            I still wouldn't write a web-server in it though :->

            Phillip.
          • the CPAN of php would be PEAR (pear.php.net)

            one of the inconsistent functions you described is strstr(). most functions that search for something in a string (like ereg* and preg*) have the arguments set up so that the needle is first, haystack last. so you get used to using them like this('findthis', $inhere), but then with strstr you go strstr($whyisthisfirst, 'wtf that makes no sense')

            just my own little two cents, keep in mind i like php and i love doing all kinds of neat shit with it like this [incise.org] and these [incise.org] and this [incise.org].

            i've played with perl a tiny bit, and while there are things i like about it (=~ comes to mind, also the general shortness of functions and constructs versus php's long_ass_function_names() like parent post mentioned), it does feel very strange - and i question the usefulness (to me). i can pretty much do anything in php that i can think of, the language doesnt hold me back very much or at all. i can write shell scripts in it too - of course people say "no no!! php is for webpages!!", but it's as fast as anything else, and i'm familiar with it so i can be very productive.

  • Let me put in a plug for bozohttpd (Score:5, Informative)

    by revision1_1 ( 69575 ) on Monday November 25, 2002 @09:26AM (#4750971) Homepage
    ...available here [eterna.com.au]. I've had it running on a 386 with only 4MB RAM [packet.node.to] running the NetBSD "tiny" distribution.

    Small footprint, pretty functional: HTTP, CGI, etc. It's referenced in the BOA docs.

  • Anything in between (Score:2, Interesting)

    by Anonymous Coward
    OK Boa is good for running on a 2mb 386, but I would like to host a domain web with some more features than it could contain. With apache needing at least a 200mhz pc and a hefty speck of ram, what is there for the middle ground, when you have a 486 or early pentium sitting around and should be put it to work?

  • This comes down to.. (Score:3, Interesting)

    by deppe ( 27130 ) on Monday November 25, 2002 @09:37AM (#4751051)
    where the www is heading, IMHO. Seven years ago, anyone was hardly using dynamic stuff on the web, and IIRC back then it was mostly flat HTML.

    But today, when 90% of the stuff served (besides images) by web servers are dynamic content, why does a web server like this get a headline?

    Ok, I know it does CGI, but come on, CGI is as dead as Ultrix.

    I'm not trying to let this project down. I'm sure there are plenty of happy users that don't need the "bloat" associated with Apache, IIS and other servers--but I'd be surprised if they did anything more advanced than the occasional photo album homepage.

    We all use bash (mostly). Not because it's the smallest, but because it does everything we've come to expect from a shell.

    To me, Boa seems a lot like the effort to rewrite the unix utilities in asm to reduce size. It's a challenging excersise, but in the long run it's going nowhere.

    • CGI is as dead as Ultrix.

      Anyone ever noticed how dynamic pages are much more likely to get /.ed than static ones? There are uses for PHP/MySQL or whatever, but fast it aint, and a lot of the time it seems to be used because it's A Good Thing rather than because it is actually necessary.

      For relatively simple tasks, a standalone CGI script is always going to be faster than a generic DB solution. For really complex tasks, CGI provides far more flexibility. For a lot of jobs in the middle, a DB-driven embedded scripting solution may be just what is needed, but there's still plenty of work for CGI at the edges.

      One of my programs writes static pages that you can edit via a web interface. I haven't load tested it yet, but I'd be willing to bet that Apache serving static pages uses far less resources than Apache building PHP/MySQL pages. If BOA will serve static pages faster than Apache, the performance benefits of producing static pages must be even clearer.

      • I agree that people often use dynamic pages because of the buzzword factor, not because it's the best. For instance, my web diary is only updated when I write something, not whenever somebody reads it. So a dynamic database solution would be just silly. I have a Python script to generate the HTML when I write the entries, and the server is Boa on a POS 486 running NetBSD. Slashdot that!

        I do like the features of Apache, for example when the site needs PHP+MySQL. But it's the right tool for the right job. And I keep that 486 from polluting the Earth on an 'acid trip' to China.

      • I'm sensing a bit of misunderstanding about what CGI actually is...

        CGI stands for "Common Gateway Interface". It provides a standard by which http servers can communicate with external programs... basically, anything other than static HTML files is "CGI".. .php, perl, asp, exe, etc...

        That being said, your post makes no sense.

        • CGI stands for "Common Gateway Interface".

          Yes, but the common usage of the word has moved on a bit. Just as, although PHP stands for Personal Home Page, it gets used for non personal websites, and not just on home pages. I think my use of CGI to mean 'CGI scripts in languages such as Perl' is pretty common practice.

          That being said, your post makes no sense

          True, but in that case half the posts on this topic and some of the original article are a bit hazy too. When the posting to which I replied says 'CGI is as dead as Ultrix', because of the wonders of dynamic content, he is either talking rubbish or using CGI in the same way as me.

    • Re:This comes down to.. (Score:4, Insightful)

      by Erasei ( 315737 ) on Monday November 25, 2002 @10:02AM (#4751208) Homepage
      I agree, and disagree.


      I agree that this will never replace Apache. However, from what I have read about it so far, it was never meant to.


      I disagree on the part that this is "dead". Just like Linux, web servers are going in two different directions. The first, and most common is serving web pages for web sites as we think of them today. Public sites either giving information or selling a product.


      There is a new market emerging though, that Boa will be well suited for. The advanced-embedded market. I am not talking PIC processors or having a web server in a lightbult, but the more advanced devices that need a slightly more advanced webserver, without needing things like virtual hosting. This type of web server should do very well on home routers and firewalls and such devices.

    • But today, when 90% of the stuff served (besides images) by web servers are dynamic content, why does a web server like this get a headline?

      <plug>

      Very true. That's why you need a web server like rws [annexia.org] which is tiny, and loads C-based CGIs into memory, and has a full database layer.

      </plug>

      Rich.
    • But today, when 90% of the stuff served (besides images) by web servers are dynamic content, why does a web server like this get a headline?

      My first thought is for serving images. Our server is quite heavily loaded, and it seems a waste that Apache is being used to serve up images (85% of our traffic) which don't use any of its capability.

      Phillip.

  • Stress Test (Score:5, Funny)

    by bytesmythe ( 58644 ) <bytesmythe&gmail,com> on Monday November 25, 2002 @09:59AM (#4751182)
    So was having the website linked directly from a Slashdot article their way of stress testing their software?

    Apparently, its load handling just isn't up to the task yet. ;)

  • slashdot effect and Boa (Score:3, Informative)

    by Anonymous Coward on Monday November 25, 2002 @10:29AM (#4751361)
    Several posters have commented derisively on www.boa.org's inability to take the load of a slashdot effect. These comments miss the mark totally.

    www.boa.org is hosted at no charge by Russ Nelson. I don't thank him often enough for this help. He provides similar service for selected other community projects, too, check out http://www.russnelson.com/ .

    I also don't hold it against Russ that he doesn't use Boa for his web server. He has other things on his mind than learning about one more piece of software; he used Apache before he hosted Boa, and he continues to use Apache. It does the job for him. If the site acts slashdotted, knowing Russ, I suspect his pipe is clogged, and there's not much he can do about that.

    So if y'all want to slashdot a Boa server to see if it holds up, pick something other than www.boa.org. There are plenty to choose from, including some that wouldn't even notice the slashdot effect.
    • Thanks, Larry. Remember that I offered to run boa for boa.org after I switched to binding Apache on a per-IP address basis? I'm still happy to do that. It wouldn't have helped, though. boa.org is only a 166Mhz machine with 64MB RAM connected via 2 T-1's. Hardly up to even a minimal slashdotting.
      -russ

  • Yeah, we only need one webserver, (Score:3, Insightful)

    by slycer9 ( 264565 ) on Monday November 25, 2002 @10:32AM (#4751376) Journal
    Just like we only need one OS, one CPU architecture, one RAM standard...come on, I don't understand all the bashing BOA has received here. Sure, it's not my HTTPd of choice, nor is it for a lot more folks, that doesn't negate the fact that it's more than sufficient, yea, even perfectly tailored for others. The very thing a lot of people here are ranting about is the very thing that makes OSS different from the 'enemy'. So you don't like it, so you don't need it. Someone else does, so let it be.

  • Pretty nice server... (Score:5, Funny)

    by mindriot ( 96208 ) on Monday November 25, 2002 @10:36AM (#4751396)
    ...with an especially nice screen shot [boa.org]... :-)

  • Where do people get stuff like this? (Score:5, Informative)

    by jefp ( 90879 ) <jef@mail.acme.com> on Monday November 25, 2002 @10:42AM (#4751436) Homepage
    >There is a pretty new

    It's not new. As the linked article says, it's been around since 1995, so it's almost as old as the web.

    >and little known

    I link to it from the thttpd page, which gets a quarter million hits per month, so I guess I've done my part to make Boa better known.

    >it is only CGI-based.

    I don't even know what this means. It serves files using select() and non-blocking I/O, not CGI. It implements CGI for external programs. Perhaps the author meant that CGI was the only option for external programs.

    >preliminary benchmarks against Apache and thttpd

    As others mentioned, no, there are no Apache or thttpd benchmarks in the article. No doubt it's much faster than Apache and about as fast as thttpd, but experience shows that very few people care about web server speed.

    >Boa (running under Linux)

    I keep telling people that if they are one of the few who care about performance enough to run a specialized NBIO web server like thttpd or Boa or mathopd, they shouldn't throw away half their performance by running Linux. Use FreeBSD.


    • Indeed, the original article seems to have been written by someone who literally fell out of the sky and decided that he needed to write a review of webservers.



      I'm not sure about how few people know about boa and thttpd, but neither of them are new and both of them make excellent webservers. I ran two virtual hosted (admittedly low traffic) websites using thttpd for years on a P5 133 with only 32M of memory. It's dead simple to set up,
      efficient and fast. I also evaluated boa, and found it to be excellent as
      well, I picked thttpd because I liked its virtual hosting a tiny bit better and thought I might make use of throttling at some point.



      I keep telling people that if they are one of the few who care about performance enough to run a specialized NBIO web server like thttpd or Boa or mathopd, they shouldn't throw away half their performance by running Linux. Use FreeBSD.


      I do run FreeBSD too. While I'm not sure about
      the relative speed of both, I wouldn't dismiss
      Jef's comment out of hand either, he's done
      benchmarking on a wide variety of systems as part
      of his thttpd work.


  • Hydra: a Boa based web server (Score:5, Informative)

    by Anonymous Coward on Monday November 25, 2002 @11:03AM (#4751597)
    A very nice and fast web server is Hydra
    [ http://hydra.hellug.gr ] . It is based on boa.

    Here is some info from the site

    Hydra is a high performance multi threaded HTTP web server. Unlike traditional multi threaded web
    servers, Hydra uses a constant, but configurable, pool of threads, and each thread can handle several
    connections by multiplexing the connections. This may remind you a non blocking server, and this is
    true, but Hydra has not the killing limitation of a non blocking server, which is that they cannot use
    more than one CPU. Hydra will take advantage of every available CPU in a system.

    It supports many thingsa that boa doesnt, like

    virtual hosts
    cgi 1.1
    SSL 3.0/TLS 1.0
    PHP and other scripting languages.

  • Web Server Survey - October 2002 (Score:5, Informative)

    by gbitten ( 306952 ) on Monday November 25, 2002 @11:15AM (#4751703)
    Statistics from Netcraft [netcraft.com]:

    WebServer Sites
    Apache 21258824
    Microsoft-IIS 10143822
    Zeus 711957
    unknown 496657
    Netscape-Enterprise 465337
    Rapidsite 411267
    thttpd 322974
    .
    .
    .
    .
    Boa 463
    • Yeah. :-) However, even I admit that if Netcraft counted by IP address instead of by virtual hostname, thttpd's share would be much lower. There are a few huge ISPs that run it - a single thttpd process on a single CPU serving tens of thousands of hostnames. This is nice, but it's not really comparable to Apache's millions of real sites.
  • Since we are on the topic of web servers ... I dont supose any of you great peoples out there could help me out. I am trying to do a fairly small website on a fairly small bandwidth budget and I have to use Red Hat 8.0 and apache 2.0. Well, somehow I would like to use mod_gzip to save on the bandwidth. Is there a relatively easy way to do this?
    • If running PHP scripts, add the follow lines at the start:
      ini_set('zlib.output_compression', 'On');
      ini_set('zlib.output_compression_level', '3');

      It will gzip your pages as they leave the server. To save on cpu, I cache my HTML pages... then also system() call to gzip it in the same dir. I then:
      if (strstr($HTTP_ACCEPT_ENCODING, 'gzip'))
      { serve_gzipped_file; }
      else { serve_uncompressed_html }
      It means the server doesn't need to gzip the file on every single request.

      Phillip.

  • "Medium-range" system, ha! (Score:4, Insightful)

    by Wonko42 ( 29194 ) <ryan+slashdot@noSpam.wonko.com> on Monday November 25, 2002 @02:11PM (#4752913) Homepage
    I spurted Coke out my nose when I got to the benchmarking portion of the article, where the author calls his 700MHz Duron system with 384MB RAM a "medium-range" system. Ha! Medium-range maybe if you're talking about big fat corporate servers. I host The Uptimes Project [wonko.com], which handles over a million database-driven dynamic page hits per day (including pages that generate large graphs on the fly), plus several other medium-traffic sites, all on a 350 MHz Pentium II running Apache under FreeBSD. This little server handles all that traffic without even blinking.

    Before this, I used to host a medium-traffic database-driven website on an old Pentium 166 with 64 megs of RAM running -- get this -- Windows 2000 Server. And it never blinked either (except when I got Slashdotted once; that really hurt).

    Anyway, in an article about a great low-overhead super efficient webserver like Boa, I'd really like to see benchmarks on systems that are actually low-end, as opposed to systems that are low-end if your other server is a quad Xeon with 16 gigs of RAM.

  • I wrote boa... (Score:3, Interesting)

    by entropy42 ( 109731 ) on Monday November 25, 2002 @08:05PM (#4755574) Homepage

    Fascinating to see something I wrote almost ten years ago turn up on slashdot as "new."

    I wrote it on a dare, sort of. There weren't any single process web servers at the time and a friend of mine said "it shouldn't be that hard..." I named it boa because my pet at the time was -- wait for it! -- a boa constrictor.

    Gee, that's it. Yay for open source living ten years on its own.

    -- psp [livejournal.com]

    • Well, first of all, thanks for the great server! I'm currently running it to serve my homepages on a 486 [homeunix.net], though I first used it about three years ago.

      I thought the explanation for the name was here [tuxedo.org], where boa is roughly a synonym for fat pipe -- something you need a fast server to saturate.

  • I first came across Boa a couple of years ago because it was running
    on the Axis webcam, which is a webcam running Linux in 8 MB of RAM and 2 MB of Flash ROM. It
    was impressive to see such a small footprint web server being used in production for an embedded appliance, running Linux.

    Just last week, I wanted to implement a custom server for my house; I have a Model 28 teletype, which I wanted to hook to the ethernet. I took
    an old PC, and downloaded a copy of Boa. I then added code to it's main select() loop to service the serial port connected to the teletype. Now I have a state of the art ethernet-to-teletype gateway machine. It was easy to do because Boa is
    simple and easy to understand. So people whining about which web server is "faster" are missing the point entirely; Developer's time is worth much more than CPU time in most situations. And developing using Boa's source base was the best option for what I needed to do.

    Free Software! YEAH!

Slashdot Top Deals

"Being against torture ought to be sort of a multipartisan thing." -- Karl Lehenbauer, as amended by Jeff Daiell, a Libertarian

Close