Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
IBM Software Linux

Kernel Comparison: Web Serving On 2.4 And 2.6 43

Posted by timothy from the onward-and-upward dept.
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."
This discussion has been archived. No new comments can be posted.

Kernel Comparison: Web Serving On 2.4 And 2.6 More

Kernel Comparison: Web Serving On 2.4 And 2.6

Comments Filter:
  • 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.

    • Re:Stop pushing. Its all linux (Score:5, Interesting)

      by MBCook ( 132727 ) <foobarsoft@foobarsoft.com> on Tuesday February 10, 2004 @10:19PM (#8244578) Homepage
      Did you even read the SUMMARY? On the system they showed, 2.6 performed dramatically better in EVERY AREA. Now if you are running a 128k processor megacomputer with 12 terabytes of RAM and ueberbit ethernet connection, maybe you don't need the performance increase because your computer could serve pages to every other computer ever built without breaking a sweat, but for people with NORMAL comptuers, that isn't the case. Upgrading to 2.6 is basically getting a free performance boost.

      You were having problems with your current webservers? They can't serve pages fast enough? You'll have to spend $50,000 to upgrade so you can handle it? Put 2.6 on! You might be able to hold off that upgrade for 6-12 months, by which time that $50,000 will buy you much more computer than it will today (not to mention you could invest that money and have more by then).

      What do you call a FREE PERFORMANCE UPGRADE? You call it good!

      Besides, it doesn't matter if it needs a "little while to iron out." If you just blindly deploy new kernels on production servers with no testing, you deserve the flack that will come you way if you get bit by a bug.

    • Re:Stop pushing. Its all linux (Score:5, Insightful)

      by Vilim ( 615798 ) <ryan.jabberwock@ca> on Tuesday February 10, 2004 @10:28PM (#8244605) Homepage
      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

  • Thanks SCO! (Score:5, Funny)

    by Anonymous Coward on Tuesday February 10, 2004 @09:59PM (#8244520)
    See, all that Unix code that IBM stole from SCO and inserted into the Linux kernel was worth it!

  • Why upgrade? (Score:4, Funny)

    by flikx ( 191915 ) on Tuesday February 10, 2004 @10:10PM (#8244560) Homepage Journal

    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?

    • Re:Why upgrade? (Score:5, Informative)

      by WasterDave ( 20047 ) <davep@zedkep.cAAAom minus threevowels> on Tuesday February 10, 2004 @11:06PM (#8244892)
      In the case of RH5.2, security. I hope you've been doing the furious quantity of patching necessary to keep that secure. If not, I'd seriously consider moving to Debian. You still have to secure it, but it's really easy to do.

      The small performance boost, according to this paper, is large. Huge, much the same as the scalability boosts that came in as a result of the mindcraft benchmarks. However, they are for the most part improvements in SMP. There are also some "responsiveness" improvements in the scheduler.

      Should you move to 2.6? Probably not. As far as I can tell the gains are on big iron, really really small iron, and the desktop. I'm sure as hell not moving off 2.4 any time soon.

      Dave

    • Re:Why upgrade? (Score:4, Funny)

      by scishop ( 622414 ) on Tuesday February 10, 2004 @11:09PM (#8244930)
      A "small performance boost"? IT'S FIVE TIMES FASTER! Any smaller and it would be in hyperspace.

    • Re:Why upgrade? (Score:2, Informative)

      by Sepper ( 524857 )
      Aside from a small performance boost

      Small...right... i'll refer you to the text of the article:

      Conclusion
      We've shown that, using a typical test scenario -- Apache/WPT on an 8-way SMP IBM xSeries system -- the Apache server has better scalability and performance on the 2.6 kernel compared to the 2.4 kernel. On the same system under the same workload, the Apache server with 2.6.0-test5 kernel more effectively used system resources and served 5 times more Web pages than the 2.4.18 kernel did. This real
  • 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 performa

  • A marvelous understatement (Score:5, Funny)

    by leifw ( 98495 ) on Tuesday February 10, 2004 @11:55PM (#8245314)
    From the article:
    "O(1) scales well..."

    No, really?

  • Consumes more RAM... (Score:3, Informative)

    by gregfortune ( 313889 ) on Wednesday February 11, 2004 @12:20AM (#8245514)
    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.

    Of course, this is just a benchmark ;o)

  • Headline: Linux Makes Bad Code Look Better (Score:5, Informative)

    by LunaticLeo ( 3949 ) on Wednesday February 11, 2004 @02:03AM (#8246207) Homepage

    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 [twistedmatrix.com] and POE [perl.org], or Event-thread hybrid systems like SEDA [harvard.edu].

    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 [kegel.com] to program [pl.atyp.us] network servers.

    • Thank you for your links. Most informative slashdot post in ages!
    • Thats not informative, thats just dumb. How do you think things like I/O completion are implemented? 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. Just because you're doing it in kernel threads instead of userspace threads doesn't mean that it's not threaded.

      And I'm _really_ not sure why you're showing us a friggin

      • 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) ha

        • This is a much better post than your original one :P For one thing, you avoid the generic "threading is bad" argument.

          The main reason why people (at least on Linux & other unixy platforms) have avoided threading in really high end/scalable servers is because threads don't scale well. Well, now we've got a scheduler and thread libraries that scale very nearly 1:1. You're talking about designs that work around a problem that no longer exists (well, at least isn't as extreme - I haven't done the sort of t

    • Whatchoo talkin' 'bout Willis!? There are two fundamental approaches to high load: threaded blocking IO, or non-threaded async IO. Both are different abstractions for the same fundamental goal of adding concurrance to a system. In reality most sites will do just FINE by modelling concurrency with a threadpool and blocking IO. Sure you CAN use non-threaded (or "less-threaded") async IO, but you incur a complexity overhead (this is the "overhead" hidden by the simplicity of threads). Unless you are writi

      • Thanks for your reply. Here is my best response.

        Try to remember I was replying to a article about how fast a web-based enterprise application is affected by the new linux kernel. That means many network connections to both clients, middleware, and even databases, with high transaction rates. I am not talking about an FTP server downloading big static files to a few users.

        Unless you are writing an eBay or Amazon.com or Yahoo.com, a threaded/blocking-IO approach will work fine.

        /me smiles

        To be completel

    • 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 c
    • ...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.
    • I followed your link...

      "Throw off the shackles and learn to program [pl.atyp.us] network servers."

      ...and found this under the "Lock Contention" heading:

      "Dividing code into stages is a complicated matter of program design, so there's not much I can offer there"

      The inevitable disclaimer buried in the majority of all literature attempting to discuss concurrency. Try this [ic.ac.uk] for a practical remedy.

      = 9J =

    • i'm not sure if i'm being too picky or not picky enough with my terminology, but great event driven servers can still (and should) use threads, they just just shouldn't be spawned dynamically per request/task. so... event driven != no threads.
  • 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.

Slashdot Top Deals

Hackers are just a migratory lifeform with a tropism for computers.

Close