Slashdot Mirror

It points out some of the things to look out for in this sort of benchmark that can skew the results towards Linux or NT. In particular Linux performs better in the case of the dataset not fitting in RAM whereas NT does better if the data can all be fit into RAM. I'm not sure what the story is with ServerBench.

You can find an unbiased summary of NT-versus-Linux benchmark results at
http://www.kegel.com/nt-linux-benchma rks.html

diff -u linux/net/ipv4/tcp.c:1.1.1.6
@@ -1575,7 +1575,7 @@
add_wait_queue(sk->sleep, &wait);
for (;;) {
- current->state = TASK_INTERRUPTIBLE;
+ current->state = TASK_INTERRUPTIBLE | TASK_WAKE_ONE;

Offhand, it looks like that particular change isn't in Red Hat 6.1 or 6.2. I don't know whether this would affect ServerBench performance, though. It's hard to tell without looking at the source.

http://www.kegel.com/linux/mslinuxinde x.html

This was from last year I believe, so maybe there were some integrations since, but I doubt it. (Search for COM in the article, it's not stricly about COM.)

As for who needs COM... Certianly nobody I know of. :-) But if neccersay we can

COM on Microsoft is just crap IMHO... Why bother with it...?

It's gotta be custom since you're going to be handling 10k idle threads at any one time.

A thread per connection model is probably not the best architecture for a system support so many users. See Dan Kegel's C10K site for more info on high performance servers supporting many concurrent connections.

I'm working on an FTP benchmark; see www.kegel.com/dkftpbench

Partly in response to the Mindcraft benchmarks, I wrote several web pages which are still worth a look.
See my analysis of the Mindcraft results at http://www.kegel.com/mindcraft_redux.html,
summaries of this and other benchmarks at http://www.kegel.com/nt-linux-benchmarks.html,
or a survey of I/O techniques for web servers at http://www.kegel.com/c10k.html

Partly in response to the Mindcraft benchmarks, I wrote several web pages which are still worth a look.
See my analysis of the Mindcraft results at http://www.kegel.com/mindcraft_redux.html,
summaries of this and other benchmarks at http://www.kegel.com/nt-linux-benchmarks.html,
or a survey of I/O techniques for web servers at http://www.kegel.com/c10k.html

Partly in response to the Mindcraft benchmarks, I wrote several web pages which are still worth a look.
See my analysis of the Mindcraft results at http://www.kegel.com/mindcraft_redux.html,
summaries of this and other benchmarks at http://www.kegel.com/nt-linux-benchmarks.html,
or a survey of I/O techniques for web servers at http://www.kegel.com/c10k.html

There is definitely a problem with the 4 ethernet card configuration that the Mindcraft folk use. I personally have never used more than 2 ethernet cards on a Linux box, and that caused some problems for me at first. I can certainly imagine that 4 fast ethernet cards could make a 2.2.6 kernel sh*t a brick, which seems to be the case here. Especially see some of the absurd initial Mindcraft tests where performance falls almost to zero at one point. The link I posted above mentions the fact that the kernel starts spending all of its time in interrupt processing with high load on multiple ethernet cards.

Okay, so what do we gain from this survey? Simple, don't use a 4 ethernet card configuration on a Linux box. Period. Or do it with caution, use a 2.3.x series kernel. Stick with single 100bt configurations for 2.2.x kernels, DON'T use pre-2.2.7 kernels (TCP bug, serious performance problems may result, ahem). If you need more bandwidth than 100bt, go with gigabit ethernet, or don't use Linux (I'd be using Solaris if I were dealing with a system with that kind of load).

Better yet. I'd save my company a lot of money, and improve performance by getting 3 or 4 single processor systems, or SMP systems with single 100bt cards. I mean, all we're really testing here is static HTML or file serving. For the price of one of these whopper Dell servers running NT, I could have a FAR more efficient better performing setup. Anyway, just making some obvious points that occurred to me as I was reading through the Mindcraft drivel. They may not be lying, but they're definitely still not being honest about WHY NT appears to outperform Linux.

The real problem with the Mindcraft benchmark has nothing to do with most of what they cited: the graphs are painfully clear that the limited resource is network bandwidth. That's why it's so funny when they say "We'd never test a server that's resource-limited. What's the point?" That's what I'd ask them now.

Note that they test with one and with four processors, but do not test with one or two ethernet cards. In fact, they never mention the complete hardware configuration of the machine, so we just have to assume they used the same f*cked-up four ethernet card configuration.

There were actually benchmarks put out by c't explaining this, with graphs, and real tasks. Linux performance generally did much better until that second ethernet card was added. I'll believe them, that it's a software limitation in the TCP stack, but I'll also believe that they were exploiting a known problem in the Linux kernel--that only happens under these strange conditions--to their ends. Until they show some benchmarks with the ethernet cards mentioned as a factor.

NT vs. Linux Server Benchmarks: informative and interesting, but most of all truthful, with a link to the c't article I mentioned, and many other more realistic benchmarks.
---
pb Reply rather than vaguely moderate me.

Also Dan Kegel wrote an interesting web page in response to the whole Mindcraft NT/IIS vs. Apache/Linux fiasco and on that page are several detailed measures to improve Apache's performance under Linux:

Dan Kegel's Mindcraft Redux page
Apache Week 'zine

...as for my own personal experience w/ Apache I learned that when compile Apache, remove any Apache modules you won't be needing saves plenty of RAM, and in the httpd.conf file you want to set StartServers, MaxClients, and MaxRequestsPerChild so that Apache does not spawn new children too often -- the trick is before you start Apache look at "top" count the number of processes, now start Apache under normal traffic conditions, look at number of processes you're running now to see how many http children are running -- whatever that number is add 10, and that should be your StartServers setting. The MaxRequestsPerChild default is 30 but I like to crank it up to 300 or more so that http children are not being killed and recreated too often (the reason for that setting was to avoid possible memory leaks from sucking up all your RAM which hasn't been a problem with the httpd's I've worked with)

mindcraft redux has some very good info regarding what slowed down apache durring the last mindcraft benchmark, should give you some insight to tuning apache.

- MbM (http://linux.com/tuneup/)

If you're running Red Hat 6.0 or 5.2, this page gives instructions on how to use the truetype support that was rolled into the X font server in 6.0, or using Herbert Duerr's xfstt for Red Hat 5.2.

Debian 2.1, which I run, comes with xfstt, as well, and is available as a .deb on their site.

I understand that the other implementations of truetype support are better, but I've been using xfstt for well over a year now with little trouble. I think earlier memory problems have been handled. It is very easy to use and set up, and I can't imagine why any of the current distros wouldn't work with it.

Finally, if you are curious about the alternatives I skipped, there's already a HOWTO available at http://pobox.com/~brion/linux/Tru eType-HOWTO.html.


*sarcasm, it's only sarcasm.
----------
mphall@cstone.nospam.net

http://www.kegel.com/mindcraft_redux.html

What was he trying to do, incite a riot? And why did he not want to admit that there might be performance problems in Linux?

IMHO it's more productive to turn the other cheek, and work on fixing our own faults. That's why my page on the Mindcraft benchmarks is relentlessly objective and focused on helping everyone, rather than cutting anyone down.

Check your road rage at the door, folks. One thing that helps me is, when I write an angry email, I let it sit for a while, and then when I'm calmer, I rewrite it until I'm sure everything in it is reasonably fair and true. It's so easy to write stuff quickly that isn't really accurate.

So far, I have some info on how Apache was configured. Kernel is next.

This site is quite a good recap of the whole Mindcraft affair:

http://www.kegel.com/mindcraft_redux.html

Our development roadmap is created by the needs of the users of Linux. It's the best roadmap there is. Maybe Microsoft can help guide our development roadmap by talking up the areas that are weak in Linux. If it's FUD, it won't hold up because the Internet tends to expose that. However, if it's valid, then the Linux community will fix it.

Lack of a journalled filesystem? Okay, we'll take care of that, with SGI's help, and also the work of kernel hackers.

Lack of a GUI? Let's get KDE/GNOME more robust and stable.

Lack of a good configuration utility?

Any other perceived weaknesses? Other companies/individuals/groups can come in and fill in and then support that subsystem. There is lots to be made in that. Are you listening? Apparently, SGI is.

Maybe MS can help the Linux development effort after all. Haven't you noticed how the more the weaknesses are talked about by people, the more interest there is in fixing them?

This document shows that in the weeks after the Mindcraft tests, kernel hackers and interested parties have been able to bring Apache and Linux performance to 3 or 4 times what it used to be, and they've identified problems in the kernel that are being fixed as we speak. Sure there are weaknesses, but the biggest advantage of Linux is that there are many eyes to find out where these weaknesses are and how to fix them when they are exposed.

Like someone else here said, this is a guerilla war. The harder MS fights us, the more resources they use to extinguish us, the more people will be turned off to Microsoft and will question their practices. The more desperate Microsoft becomes, the more obvious it is that they are losing.

It's hard to flail at a moving liquid target that cannot be pinned down to one organization or group of people.

Linux grew with the Internet. It grew without any media attention. It grew and still grows because it meets real-world needs. It has nothing to do with hype. It did just fine without media attention. We basically had to force the media into noticing us. As long as it can meet real world needs for the users/developers and has a good chance of providing that in the future, it cannot lose.

See http://www.kegel.com/mindcraft_redux.html for an up to date report on how the Linux kernel people are addressing the bottlenecks that caused Linux+Apache to perform poorly on the Mindcraft test.

1. The Mindcraft benchmark, while flawed, did show real performance problems in Apache on Linux.
2. The worst performance problem was probably fixed by 2.2.7.
3. Another performance problem is scheduler overhead (the current design has trouble handling 200 running processes). A fix is in the works.
4. Dean Gaudet thinks mod_mmap_static should be able to give a significant performance boost.
5. Apache 1.x's process-per-client architecture probably prevents it from achieving the highest possible performance on static files.

See http://www.kegel.com/mindcraft_redux.html for support for the views stipulated above and continuing updates on the linux kernel team's response to the Mindcraft challenge.

The XAnim distributed with Red Hat can't handle
Cinepak avi's, for copyright reasons.

See http://www.kegel.com for a
source RPM and instructions on how to install
a more capable XAnim.