Slashdot Mirror
Kernel Comparison: Web Serving On 2.4 And 2.6
An anonymous reader writes "Many improvements have been made in the Linux 2.6 kernel to favor enterprise applications. This article presents results from the IBM Linux Technology Center's Web serving testing efforts, comparing the Linux 2.4 and 2.6 kernels from various aspects. The highlights here are the key enhancements in the 2.6 kernel, the test methodologies, and the results of the tests themselves. Bottom line: the 2.6 kernel is much faster than 2.4 for serving Web pages, with no loss in reliability."
At this point 2.6 is _far_ better than 2.4 at the same point in the development cycle. Linus actually ripped out Rik van Riel's VM code and replaced it with new VM code. At this point 2.6 is FAR more stable than 2.4 at a similar stage, there really is no reason for the average user not to upgrade
History will be kind to me, for I intend to write it - Sir Winston Churchill
I don't know about you guys, but I'm not too sure that I would describe this article as an examination of an "Enterprise application" on Linux.
Enterprise applications are many things to many people, but rarely are they web servers.
Enterprise servers are generally run complex applications running many complex operations.
While I'm sure IBM's web server is very good, I don't think that it would be typical of an "Enterprise application".
My point is, while I'm sure this is a fantastic article examining performance improvements between Linux kernel versions, let's not pretend it's something that it isn't.
Thats not informative, thats just dumb.
I think I'll disagree with you on that.
How do you think things like I/O completion are implemented?
I've heard that the have a thread waiting for each completion port, sorta like the aio_* implmentation on Irix. But, you might be thinking I am some Microsoft stuge, just so you know I don't do windows; sometimes FreeBSD (cuz it has some cool stuff), but nearly exclusively Linux for the last 10 years.
Crappy threading performance on Linux (and in unix in general) has historically been because of crappy threading libraries, and because process creation is relatively cheap so people tended to just fork children instead of spinning threads.
I think I have used those very words myself.
Just because you're doing it in kernel threads instead of userspace threads doesn't mean that it's not threaded.
I never suggested user space threads. They don't require kernel intervention, but they don't utilize multiple CPUs. And M:N threading libraries are out of fashion. Apparently all those smart people realized that two levels of schedulers were hard to make fair and fast at the same time. NGPT lost in favor of 1:1 in NPTL (LinuxThreads just blew chunks). Solaris9 now makes 1:1 threading library default, where Sun used to trumpet the glories of their then new, now old, M:N thread library (now if they would just shoot mtmalloc in the head and be done with it).
And I'm _really_ not sure why you're showing us a frigging Python framework as some sort of example of super-performant network programming. Pythons great and all but a performance monster it is not. "Yeah, boss, we use a runtime-compiled interperter for all our performance-critical code, but by God we avoid context switching!"
As I said in another post in this thread: scalability comes from design not from optimization. If Perl or Python or Java are a constant factor slower, but I use a better algorithm, I can beat C/C++ hands down. I saw someones sig that said something like "If it can scale, I can buy performance." So while scalability != performance there is a relationship. And with a bunch of cheap PCs running Linux, I can crush someone elses Apache/JBoss/Websphere "enterprise" app running on some Sun E15K monstrosity.
-- I am not a fanatic, I am a true believer.
...around poorly designed operating systems where threads are slow. The cool thing about 2.6 is that there now is one less motivation for using such kludges.