An Overview of the Boa Web Server
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."
If Boa is too constricting, you might want to switch back to good ol' Apache
Bah dum bah!
Nice metaphor. You can make pie out of both of them.
How well does it fork?
The best option would be to go get the 486, and bash it over the head of the gumboid who told you a 200mhz pc is needed for apache
somehow i knew you'd be sending us to mrtg charts, but i was hoping it was going to chart eth0 traffic or something.. you know, give us a goal, something to work towards!! :)
Intelligent Life on Earth
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.
bytesmythe
Hypocrisy is the resin that holds the plywood of society together.
-- Scott Meyer
Bah, PHP? Try awk, Bash or Postscript for a thrill!
Programming can be fun again. Film at 11.
no, comparing apache and boa is like comparing apples and oranges
you insensitive clod!
-- SouNerd.com
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.
/., we don't do things that way.
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 or where, but here on
I'll have something intelligent to add one of these days...
...with an especially nice screen shot... :-)
That's because you're doing it wrong. You compare by cross multiplying. Instead of (featuresApache)/(priceApache) vs. (featuresOther)/(priceOther) you do (featuresApache)*(priceOther) vs (featuresOther)*(priceApache).
And Apache wins.
Bad analogy, wrong use of cliche
10-yard penalty, replay 3rd down!
Non blocking I/O is (fairly) portable in terms of the API, but not in terms of performance.
Some platforms fall to pieces when you try to deal with more than a handful of simultaneous connections. To avoid armagedon on those platforms, you are back to multiple threads/processes, each of which handles up to a fixed maximum number of connections. Of course you have to pool the threads/processes, and synchronize between them, so you end up with all the complexity of a multithreaed webserver, along with all the complexity of a non-blocking I/O webserver.
Besides, I have never seen a "real" non-blocking I/O application that didn't have a switch statements with one of the cases having the comment: