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."
I see a great push everywhere for everyone to start using 2.6. Why, if youre successfully using 2.4 or 2.2 in your current installation. I remember 2.4 took a LITTLE while to iron out.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
See, all that Unix code that IBM stole from SCO and inserted into the Linux kernel was worth it!
This is not a troll, but a serious answer.
None.
Aside from a small performance boost, is there really any reason to update perfectly stable systems? My shop has been using a few boxen running RedHat 5.2 for almost seven years now. If everything is stable, why upgrade?
One future, two choices. Oppose them or let them destroy us.
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.
"O(1) scales well..."
No, really?
While the performance gains are impressive (about 5 times as many pages under 2.6) it also shows that 2.6 used 5.6 times more RAM to serve the increased number of pages. If RAM on the system isn't limited, the performance gain is insane. If the system is already overloaded w/respect to RAM, it likely won't help much and there's a *slight* chance it would actually perform worse.
;o)
Of course, this is just a benchmark
The new linux kernel is great, but the reason the this particlular kernel results is better performance ("5 times better") is because the application framework it is testing is horrible.
All of the "enterprise" applications in this test have several performance cripling features in common: socket per thread connections, fundemental reliance on threads, and massive memory foot print. Apache has one thread/process (the diff is a stack) per connections. Java requires a sizable multiple of memory usage as most other application languages (C/C++ obviously, but also Perl, Python, and PHP). J2EE is an inherently thread driven programming framwork.
So yes, Linux 2.6 ameliorates the downsides of unnecessary use of threading. It makes thread creation and context switching even faster on the Linux platform.
And Yes, Linux 2.6 memory management is fundementally better. Reverse Page Table Entry mappings make finding victim pages better; and it is designed to avoid victimizing active pages better.
But could you all imagine if people were designing fundementally better application framworks? Event driven application architectures like TwistedPython and POE, or Event-thread hybrid systems like SEDA.
The performance stats given in that article are shit, complete utter shit. I know. In the proprietary world I work in, I code faster programs on the same Linux platform on a daily basis; orders of magnitude faster.
All the accomplishments of Linux 2.6 can be used for true performance programming. I plead with you all, stop using Threads until you know what they are good for. Stop using the stack to maintain your program state. Throw off the shackles and learn to program network servers.
-- I am not a fanatic, I am a true believer.
i was just wondering if there would be
...
:P
any improvement to scheduling on
two processor system if it
wasn't SMP (symmetric multi processor)
but asymmetric.
one processor doing the scheduling (over kill?)
for the second processor
if you had 8 processor two processors would do
the scheduling. this is interessting 'cause
as far as i can tell the scheduling idea
of linux is kindda using two "processes"
to implement the schedular. with eight
processors and two processors doing the
scheduling maybe get a dimension higher (4)?
i never had a multiprocessor system or even
hyperthreading, but it sounds interessting
considering the possibilty running a "real"
OS on one processor and having it run
a virtual box (or a second layer on the second
processor "slut processor")
2 cents
Quite a bit comes from IBM's RCU, which may or may not be SCO code, depending on what the Judge thinks of the contract Sequent signed with SCO.
Don't think so anyway. According to the author
Ingo Molnar:
On Thu, 18 Dec 2003, Ingo Molnar wrote:
> Jeff Garzik wrote:
>
>>Are you sure? I could have sworn Ingo made the scheduler magically
>>HT-friendly...
>
> nope, it's not in 2.6 yet. This area is still under development,
> with various approaches being considered.
>
> Ingo
I would be interested in knowing which MPM module(s) they used with Apache in their testing. Whether they used worker, prefork, or something else could make a big difference in serving performance. It would also test different areas of kernel performance I would think.
TwistedPython runs everything from a single thread. Even if you have multiple threads, only one thread can be running at a time due to Python's GIL (Global Interpreter Lock).
Diregard the fact that TwistedPython is still in its infancy and thus immature compared to its rivals.
The fundamental problem with it is that it will not scale well to multiple processors because all of the python threads must interact and share the same memory. It's not like Apache which has one master process that handles incoming connections, and several children distributed across the processors, using seperate sections of memory - it is only a single process with multiple Python threads, forced to run one after another thanks to the GIL.
Apache scales far better than TwistedPython. When you have a properly scaleable database backend, or some kind of application logic layer that can scale, then it behaves very well as the load increases and on more advanced hardware.
Understand that I'm not saying that "TwistedPython Sux!" I am saying that I won't be using it for an application server that must scale. Once Python overcomes the GIL problem (and offers shared memory for Python objects) then TwistedPython may begin to have some hope of actually scaling.
The radical sect of Islam would either see you dead or "reverted" to Islam.
Stop using the stack to maintain your program state.
Sorry, I can't get behind that approach.
The most important thing for a server app, up 24/7, is that it is CORRECT. Programmed correctly, proven correct. The easier this is, the faster we can ship and upgrade with confidence. Breaking your application down, you may find that certain problems are best solved with one programming technique or another. Perhaps one search is best modelled with recursion. So do it that way. If you did it without recursion, maybe you could wring a bit more performance out of it, but let's just make it work CLEARY, CORRECTLY first. Optimize later. Anyone from a CS, especially functional, background will naturally see certain (not all, I hope!) problems as falling out of recursion. Recursion requires using the stack to maintain program state. And it's the right thing to do in many cases. Optimize later.
...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.