Slashdot Mirror


Web Server Comparisons

Anonymous Coward writes "ZDNet is running a story today (yes I know it's Christmas) about several web servers. They have apparently benchmarked these servers. They tested Sun, Linux and MS servers. I'm not sure that I like the way they tested, they didn't include BeOS or tune the configs. Check it out at their web site"My fault - this is totally out of date. Blame it on the egg-nog.

7 of 212 comments (clear)

  1. Hemos - read the dateline by father_guido · · Score: 5

    May 6 1999? That's today?

    Man, I better get ready, the 4th is coming up soon!!! Gotta find the best fireworks vantage point...

    ;)

  2. nope... by Issue9mm · · Score: 5

    Nope, this isn't cutting it... I'm not that big a FreeBSD lover, but I am taking exception to the fact that it and its brethren are continually left out of these benchcrafts...er, marks...

    Because of its speed, ease of setup and administration, and a dizzying array of add-on and development products from Microsoft and third parties, we award Microsoft's Web platform--Internet Information Server (IIS) running atop Windows NT--our Editors' Choice.

    Of all the reasons NOT to choose a web server, I think they hit them all. Granted, speed is important. But ease of setup? administration? (maybe) add-on and development products? (must mean ASP, & other proprietary compoonents... that "mixed web" environment they spoke of earlier in the article must not be that important)

    Whatever happened to security, or - since "ease of setup and administration" are such a factor, how about security "out of the box"? Granted, I'm glad to see Linux listed, but (no offense) Caldera's not exactly the distro I'd pick for my web serving. Nor would I use Stronghold. (personal prefs, made through experience)

    Just seems like ZDNet refuses to just get things right. Ordinarily I hate to be the crybaby bitching about the testing, the methods/materials, etc..., but I'm really becoming more and more disappointed in ZDNet's lack of integrity.

    Flame away...

  3. Anyone else notice the cache comment? by color+of+static · · Score: 5

    They "tuned the cache" to the point that none of the servers went to disk for their workload. That right there gave NT an advantage. In a real world scenario I'll be out to the disk all the time. I'll be there to get my data during misses, to write my state info for transactions, to log things.
    How much logging was the NT server doing? If it wasn't a lot then they took out the disk subsystem from the equation.
    The whole reason they used the 2.0 kernel was fishy at best also. 2.2 TCP stack broke communications with their win 95 clients?
    Finally, why on earth would I want to do hundreds or thousands of SSL transactions in software. If you are doing more then a few a second you really need a hardware SSL brick or card, which works with all the tested platforms. These people obviously don't understand but one set of solutions.

  4. As usual... by Alex+Belits · · Score: 4

    they repeat bogus reasons for using Microsoft servers ("if you have existing business logic, such as pricing strategies, written in Visual Basic..." -- hello, you want to call Visual Basic script, written by an accountant's assistant from HTTP server in secure environment?), measurements made with CGI scripts on Unix (heard of anything else?), their WebBench tests that have nothing to do with real-life environments other than that it uses HTTP, never use Gigabit ethernet cards in their low-latency tests, "demonstrate" that SSL servers are dominated by Microsoft IIS by splitting branded Apache-derivatives into different categories, don't include Unix servers other than Apache and Netscape, omit *BSD, etc.

    In other words, usual advertisers-driven "Editors' Choice" stuff from ZDNet.

    --
    Contrary to the popular belief, there indeed is no God.
  5. "Webbench" of 600 or 4000 - It Just Doesn't Matter by rbrander · · Score: 4
    Their graphs show the worst servers flattening out at "Webbench" numbers of 600, where the best go up to 4000.

    They don't show the formula that gives the number, but from similar web benchmarking reviews, I know that even the worst ones are serving up hundreds of page-views per second. The best are maxing out multiple 10Mbps Ethernet cards - i.e. you need a T3 line to actually provide the bandwidth you're serving.

    If you can afford that, you aren't reading Ziff-Davis to make your product decisions or even find your shortlist.

    These kinds of servers are only needed by the big ISPs and the eBays of the world - the whole review is only of interest to a few thousand webmasters.

    My employer is a city government serving some 860,000 people with a mostly static, partly active web site about all their city services and taxes and utility bills - and it rarely exceeds a few tens of pageviews per second.

    Forget all the sniping about tuning and benchmark methodology; the really stupid thing about these product comparisons is that they imply that more than a fraction of one percent of their audience should even care about which one wins. For the rest of us, a free product running on a free OS and hardware that costs less than the monthly cost of our Internet bandwidth can meet all our needs.

  6. Discuss why Linux didn't do as well as you hoped? by Speare · · Score: 4

    Maybe you'll consider (Score -1: Troll), because I'm suggesting rational discourse over religious whining.

    It appears from this thread of comments that the slashdot community is unhappy about all sorts of things that don't seem central to the issue. The comments becry ZDNet's advertising vs testing integrity and methodology, Caldera distro's shortcomings, Stronghold's performance vs other Apache releases, and why they didn't choose the EndOS-BeOS of solutions.

    The issue, as I would see it, is "what can Linux do, to fare better in third-party comparisons?"

    It appears from the article that there are several reasons that ZDNet listed why they felt Linux/Apache/Stronghold was limited. Let's start with those.

    • ZDNet chose to tune ALL the servers to have 68Mb of web source material and at least 68Mb of memory disk cache.
      Why did this give NT an unfair advantage? Why does Linux (or particularly the Caldera distro) solution not deal with RAM-rich servers as well as NT? I think the poster who complained of this meant the inverse: if it were a RAM-poor server, Linux would have the advantage in disk accesses.
    • ZDNet used multiprocessor servers.
      All religious handwaving aside, why did NT fare better by spinning threads than Apache could do by spinning processes? What is the big bottleneck in managing a process, that managing a thread doesn't have? They were using a brand-new MP kernel straight from Linus. Will the Linux kernel mature to deal with SMP situations and massive numbers of similar threads or processes better?
    • ZDNet suggested that in-process programming worked better for all the hairy e-commerce they decided to test.
      Though I think they should have configured some PHP or Mod_Perl into their mix, just as they had to bend to the SSL3-only constraint for another platform, they have a point. Writing modules is the way to go, to get inside the server and run fast. Besides PHP and Mod_Perl, where can Linux go to improve?

    Most of these seem to suggest that ZDNet could have configured their Linux servers more like real-world Linux admins would, and would find better performance. This does talk poorly of Linux's ease-of-use, though they lay it on thick when they cry about config files. This is an education issue.

    Slashdot is already slanted (pardon the pun) towards the Linux solution. Not every problem is a nail, and there are even different hammers for different nails. Let's be objective and constructive, instead of whining about every possible outside excuse. Improve the tool, and the tool will become the standard.

    --
    [ .sig file not found ]
  7. Re:Old stuff; any new developments? by orcrist · · Score: 5

    Also, what is the state of threading in apache?

    Apache 2.0 will be a hybrid forking/threading server thus giving it some of the speed advantages of threading while maintaining the advantage of multiple processes that every one of these benchmarks never mentions: stability.

    If for some reason one of the threads in a multi-threading server crashes, it can bring the whole server down with it. If one of Apache's child servers crashes... Apache forks a new one to replace it. The new design will be a compromise with several preforked children, each of which is multi-threading. Then let's see what the benchmarks look like :-)

    Chris

    --
    San Francisco values: compassion, tolerance, respect, intelligence