Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Apple Businesses

PPC Linux vs. Mac OS X Server: Linux Edges Out 397

Spencerian writes "Mac OS X is a very promising new BSD variant, but how does it rate as a server? Byte.com writer Moshe Bar has made an extensively balanced performance comparison of Mac OS X Server 10.1.5 versus SuSE Linux PPC with the 2.4.19 kernel. Both operating systems ran on the same hardware: an Xserve 1U rack mount server from Apple. While /.ers may guess (correctly) at his results, Mac OS X Server 10.1.5 wasn't as far behind the curve as you might think. Performance might've been better if Moshe had Mac OS X Server 10.2, with its faster GUI and other enhancements, but still, it appears that Mac OS X Server 10.1 was doing pretty good for a 1-year old."
This discussion has been archived. No new comments can be posted.

PPC Linux vs. Mac OS X Server: Linux Edges Out

Comments Filter:
  • by Anonymous Coward on Tuesday October 29, 2002 @04:02PM (#4558830)
    to compare, say FreeBSD vs. OS X?
    • It wouldn't ... (Score:3, Informative)

      by wasp sting ( 602449 )

      FreeBSD PPC support is still wearing diapers, see the current status [freebsd.org].
    • by Billly Gates ( 198444 ) on Tuesday October 29, 2002 @07:06PM (#4560188) Journal
      ....then we will talk about comparing apples to apples. I don't believe they exist yet.

      Netbsd and Openbsd are the only bsd distro's that are stable and out of alpha for the powerpc platform. Last time I looked at the powerpc freebsd project, the big news was that perl compilied! Obviously its very alpha and would do injustice to freebsd because the optimizations are not there and that is assuming FreeBSD would be mature enough to run these tests. Can mysql even compile on it yet?


      Also it has been said here before and I will say it again that the kernel in MacOSX is not Freebsd based!



      Its based on Mach and Nextstep! Only some of the libraries and a few programs have been ported. All the i/o code is based on Mach and not FreeBSD. Its the i/o code that needs some work.

      Also I expect a micro-kernel vs a macro-kernel flamewar to show up on this thread to explain why this is. Since both FreeBSD and Linux are macrokernel based, all of the i/o code runs in the kernel. On MacOSX most of the i/o runs in userland. They really are apples to oranges.

  • Grammar (Score:3, Funny)

    by Anonymous Coward on Tuesday October 29, 2002 @04:02PM (#4558833)
    Mac OS X Server 10.1 was doing pretty good for a 1-year old


    And "was doing pretty good" is written pretty well for a ten-year-old.
    • by poot_rootbeer ( 188613 ) on Tuesday October 29, 2002 @04:14PM (#4558968)

      Maybe it means the opposite of "was doing pretty evil". Presumably describing a Windows/IIS server configuration.
    • Re:Grammar (Score:3, Insightful)

      by rseuhs ( 322520 )
      Apart from grammar mistakes, the conclusion is also completely wrong.

      MacOSX is over 10% slower in most test, that sure as hell is not pretty good. That's bad, very bad.

      Especially if you realize that PPC is MacOSX' major (in fact the only) platform, while for Linux it's just a minor platform that receives not nearly as much attention as for example x86.

      And I guess you could still squeeze out some performance gain if you use a source-based distro like Gentoo.

  • by Ed Avis ( 5917 ) <ed@membled.com> on Tuesday October 29, 2002 @04:03PM (#4558838) Homepage
    'You have requested data that the server has decided not to provide to you. Your request was understood and denied.'

    Wow, a self-aware server that _understands_ the Slashdot effect. I wonder if it is part of their mythology.
  • by GreatDave ( 620927 ) on Tuesday October 29, 2002 @04:03PM (#4558841)
    This goes to show that Mac OS X Server does compare very well to other Unices (okay, Unix-LIKE systems) in terms of performance. With its preeeety GUI anemeties, OS X Server could be just the stepping stone we need to get more admins to switch over from M$.

    Now let's see OS X Server kill, er, compared to Windows 2000/.NET... Run, Bill, run! :P
    • Posix bases are better in general for server applications than windows. Windows is designed for users. Posix is geared towards computers. Windows is about making things easy. Posix is about making things work well. Each of these has concessions towards the other's area of expertise, but it's all a matter of which is better for the job, and if the concessions are better than the other's native functions. Damn...think i confused myself with that
      • Hear, hear... (Score:5, Insightful)

        by GreatDave ( 620927 ) on Tuesday October 29, 2002 @04:21PM (#4559029)
        Agreed... but let me throw you a curve.

        POSIX systems have extensibility, portability, multiple programming languages, a networked windowing system with your choice of WM/DE, TRUE multiuser capability, efficiency and stability.

        What does Windows have? Most of the above, specifically minus portability, the networked windows system (Terminal Services doesn't cut the cheese), efficiency (in recent versions) and stability. What Windows doesn't give you is choice. I argue Windows is not any more "designed for the user" than Unix, but rather that in Windows (or at least in each version) everything is only One Microsoft Way, and you cannot do much to change that. Microsoft also has mindshare and a $50+ stock price.

        To the topic at hand now. Apple now more or less equals Unix as far as the OS is concerned. Specifically, OS X is POSIX plus everything being pretty, and there being an Apple Way (often, multiple Apple ways such as the choice of APIs) and a BSD Way to do most things.

        This is why I argue OS X, now that it is proving itself as a server, can advance ground on the desktop and on the server.
        • Re:Hear, hear... (Score:2, Insightful)

          by b0r1s ( 170449 )
          You might consider rewording your argument to get rid of "posix systems". Windows 2000 is compliant with the POSIX 1003.1 standard.

          source [microsoft.com].

        • In name only (Score:3, Insightful)

          by GreatDave ( 620927 )
          POSIX is all about portability. The day I can take a Unix program and recompile it on Windows without the use of an intermediary API or environment (Cygwin, MS-SFU) is the day Windows is truly POSIX compliant.

          FTR, for drivers, Windows provides some POSIX support. This is why your hosts file is in a directory called etc in system32\drivers, for example. But Windows breaks POSIX in many other smaller ways. I'd really question how MS got that certification for Win2k.
  • Still wondering... (Score:3, Interesting)

    by csnydermvpsoft ( 596111 ) on Tuesday October 29, 2002 @04:03PM (#4558847)
    Why do you need a GUI on the server anyways? All it does is waste cycles.
    • by Anonymous Coward on Tuesday October 29, 2002 @04:07PM (#4558887)
      You are not required to run the GUI in Mac OS X.
    • by Jobe_br ( 27348 ) <bdruth&gmail,com> on Tuesday October 29, 2002 @04:10PM (#4558927)
      Not really. As in most Unices, if the GUI is not being interacted with, it isn't eating up any cycles, either. The scheduler just puts it to sleep, awaiting an event (interaction).

      Having a GUI on the server allows for simpler administration. Many folks that I know, that don't have a GUI on their server, also don't have a disply. Yet, they use VNC to more easily administer the server - or something like webmin or linuxconf in HTTP mode. Either way, you're still running a GUI.

      Of course, console based administration is fine, too - but, Apple is about making things simple, even if you weren't raised a systems administrator. And contrary to Microsoft, their definition of "easy" doesn't correlate with the level of insecurity the system has.

      Cheers.
      • > ...or something like webmin or linuxconf in HTTP
        > mode. Either way, you're still running a GUI.

        Not on the server.
      • by zulux ( 112259 ) on Tuesday October 29, 2002 @04:20PM (#4559018) Homepage Journal
        Yet, they use VNC to more easily administer the server - or something like webmin or linuxconf in HTTP mode. Either way, you're still running a GUI.

        Reminds me - I have a FreeBSD box that I'm too stupid/time-burdened to get X running on it's crappy video card. But it serves up a GUI over VNC just fine.

        I have another FreeBSD box that doesen't *have* a video card, and, of course, it servers KDE over VNC just fine. When I show it to MCSE types - theh sit there and stare. "b..b..but... I doesen't have a video card! How does it do that?"

        Fun to play with their little minds.

        • I have another FreeBSD box that doesen't *have* a video card, and, of course, it servers KDE over VNC just fine. When I show it to MCSE types - theh sit there and stare. "b..b..but... I doesen't have a video card! How does it do that?"

          As if windows can't do that? With VNC, no less? Maybe you'd need a card to set it up - I don't know, but I'd bet that the machine you use did when you installed it, too (though I won't bet $ on that :-)

          Actually, I have launched VNC blind on a windows box. Wait, now I'm just sounding like a sick bastard...
      • by IamTheRealMike ( 537420 ) on Tuesday October 29, 2002 @04:21PM (#4559023)
        Having a GUI on the server allows for simpler administration.

        Why bother having a GUI itself, when there's no display? Why is this better than having some admin apps that use X, so use the display system of whatever computer you happen to be at, as opposed to running a GUI that will mostly not be seen.

        Of course, console based administration is fine, too - but, Apple is about making things simple, even if you weren't raised a systems administrator. And contrary to Microsoft, their definition of "easy" doesn't correlate with the level of insecurity the system has.

        Not sure I can agree with that. Microsofts systems except in a few rare cases are not really inherantly insecure, the insecurity comes from the fact that untrained people are acting as admins, and don't really know what they're doing. So they forget to update, they run more services than they should, and so on and so forth.

        I don't believe a GUI, regardless of which megacorp made it, can replace proper training. If anything OS X Server will kind of have the same problem, as people will say "ah, if I use MacOS I won't have to think" - oops, that extra service you were running just got rooted.

        • At least those services are not turned on by default on OS X. On Microsoft OSes you would havea default install with an HTTP server, FTP server and other services and they would get installed and started with default passwords and all. Some users wouldn't even realize they were running a web server and ftp server until their system was hacked.
          • That is just so much bullshit. Windows does not automatically install HTTP or FTP servers, or anything like it. You have to specifically request that when installing.

            Granted, what you get when you do request it (IIS) is crappy to administrate and has the worst security record ever, but it is not installed by default. And when you have installed it, it does not start by itself. It does not come with "no pasword". Etc.

            That is just something I can only assume that whiny youngsters said to their parents/professors/whoever that was really mad when the computer got hit by some virus. Maybe you are one of those, covering your *ss still?

            On a side note, last I tried Mac OS X, it did by default install (and maybe even start?) an Apache server. But that was a long time ago, and it may have been a beta release.

            The real fact is that if Apple was as hated as MS, they would have as many exploits, and that probably goes for Linux. Or maybe it is that noone would pay that insane money for a machine that can't play their games just to see how it could be rooted...
      • No one to this day has been able to convince me that there is something more "simple" than a shell. Seriously, you just type text in on one line - what can possibly be "simpler"?
        • by Computer! ( 412422 ) on Tuesday October 29, 2002 @05:01PM (#4559356) Homepage Journal
          Try typing instructions into the steering wheel of your car, and see how well that works out. Maybe you could get a printed list of items inside your fridge, and after executing other commands to find out the expiration date, and how much of the item was left, you could type the name of the item, and it would appear. OR, you could just reach in and grab the milk and smell it. LIFE HAS A GUI FOR A REASON.

        • by Onan ( 25162 )
          Yeah, totally. What could possibly be easier than remembering 2211* commands off the top of your head, without having any reminder of their name, location, syntax, or dependencies at the time? That's of course ignoring the added simplicity of remembering shell aliases, your current directory, all your environment variables, invisible key bindings, context-sensitive tab completion, symlinks, named pipes, libraries, permissions...

          Hey, I use a shell ten hours a day, I'm not disputing that there are very many things for which it's a fantastic tool. But carefully selecting how you measure "simplicity" in this way is just being gratuitously obtuse.

          *items in my current path on my primary linux box
    • Man, true.

      I also wonder why a 'faster GUI' would have any impact on server performance.
    • by dhovis ( 303725 ) on Tuesday October 29, 2002 @04:13PM (#4558967)
      Yeah, I know. I just checked top on my iBook and it told me that the WindowManager has consumed 2 minutes of processor time since my last reboot 6 days ago. SystemUIServices has used another 2.5 minutes.

      I mean, thats like .04% wasted processor cycles.

      Note to the clueless, the GUI doesn't consume much processor time if nothing is writing to the screen.

    • by FatherOfONe ( 515801 ) on Tuesday October 29, 2002 @04:24PM (#4559048)
      Great question, and one the Novell NetWare guys keep asking. My answer is that if you have a shop of NT, Linux, Unix, Macintosh and NetWare, you will have to know the commands for each one. This can be a pain to do, so what normally happens is that you get someone who becomes an "expert" with one of those systems. Then comes in someone like Microsoft and says how much money they will save by "Standardising" on one NOS.

      The other issue is that if some MCSE type is not comfortable at all working on another platform then they will ALLWAYS recommend a Microsoft solution. If they walk up to a system and it has a GUI that is similar to Windows and they can do their job, they tend to be more open to using that technology. I believe that this describes a lot of people, in that they don't want to spend a lot of time learning something totally new.

      I was a Novell/Microsoft guy who decided to give Linux a try about two years ago. I found the migration easy. I used the GUI as a crutch until I could learn the command line equivilant, and found Mandrake and RedHat tools very easy to work with. Without the GUI I would still be pushing NetWare and Windows. To be honest probably Windows...

      Lastly, I have converted most of our business over to Linux now... It has run great. I do miss a good directory service and the ability to add disk space to a volume on the fly (yes I know about LVMs, but most distros don't default to it) oh yeah and a good free equivilant to Groupwise/Exchange server.

  • Here is the error I received when I tried to visit the link at byte.com:
    "You have requested data that the server has decided not to provide to you. Your request was understood and denied."
  • It would be simple to check the referring URL and if it matches slashdot.org to send back a 403.

    Has Byte been bytten in the past by the slashdot effect? (no typo - just a bad pun)

  • GUI? (Score:2, Insightful)

    by axxackall ( 579006 )
    Mac OS X Server 10.2, with its faster GUI

    I thought it's about servers. How is it important for a server to have "faster GUI"?

    • Re:GUI? (Score:3, Informative)

      by mcc ( 14761 )
      Despite what the slashblurb writer said, 10.2 isn't *just* a faster GUI. They recompiled the entire OS with GCC 3, as well as some other speed improvements. I don't know how many of these improvements will actually be useful for the kinds of things servers are doing. I know the GCC 3 thing will be some improvement, but i don't know if it will be measurable/noticable.
  • Mac OS X VS FreeBSD (Score:5, Interesting)

    by McFly69 ( 603543 ) on Tuesday October 29, 2002 @04:06PM (#4558878) Homepage
    I personally would find a comparison of FreeBSD and OS X(the deriviative of BSD) more helpful. Anyone have any articles like this?

    BTW, byte.com is /.ed. Any mirros out there?
    • by fliplap ( 113705 )
      The comparison would be pointless since people would argue that one hardware platform was better than the other, since there's no FreeBSD for PPC and there's no OS X for alpha or intel.

      Maybe you'd like to see a Darwin vs FreeBSD or an OS X vs NetBSD article? But once again, results would be kind of pointless since Darwin isn't tuned for x86 and doesn't include the kind of hardware support you would expect from a server OS. The OS X vs NetBSD one might be useful, but since not that many people run NetBSD it might not.

      I think the point was to compare 2 fairly common server operating systems on a level playing field. Of course there will still be people who argue that it was unfair and if one or the other had been tuned someway the results would be better.
  • SWAP File/Partition? (Score:5, Informative)

    by Anonymous Coward on Tuesday October 29, 2002 @04:06PM (#4558881)
    What was the swap confirguration in linux during the test? I believe it was a SWAP partition rather than a SWAP file.

    Whereas on OS X it should have been default(ed) to a SWAP file.

    The difference in performance is quite considerable because for a SWAP partition the OS doesn't have to go through a lot of IO file system code.
    • yes I agree with you infact this has been the major source of kernel panics on MacOS X that I have seen as mac people just dont understand the whole swap thing

      really its a bad comparison but if you tuned them file I/O on linux would be much faster simply because of the filesystem

      not too sure how the mach kernel in MacOS does the Unix Lites either so that would have impacted performance

      ah well what matters is functionality and they are about equal in my eyes with MacOS winning the desktop and linux the server

      regards

      John Jones
  • Put OpenBSD or NetBSD on that machine and compare. linux vs foo comparisons are boring and more of the same. (or FreeBSD if it runs on PPC these days)
  • Eh? (Score:5, Insightful)

    by zulux ( 112259 ) on Tuesday October 29, 2002 @04:09PM (#4558916) Homepage Journal
    To me, the performance of Linux over OS-X is marginal and not really worth considering. The choice really is over what the computer administrator is more comfortable with - hell, put NetBSD if it will make the administrator more productive. The server only costs $3000 bucks so screwing around just to get a 10% improvemnt is not worth it - but if Linux makes the administrator 10% more productive then do it.

    Stupid Example:

    I haven't benchmarked FreeBSD vs Linux and I really don't care - all my file servers are FreeBSD because I'm expensive and learning Linux is not cost effective (for me). YMMV.

    • Re:Eh? (Score:3, Interesting)

      Perhaps you should read this [slashdot.org]

      Maybe to you a 10% performance difference is not much, but for large sites, performance is often the deciding factor. The faster you can serve your customers, the happier they'll be.

      • Re:Eh? (Score:3, Interesting)

        by WatertonMan ( 550706 )
        That's true in general, but the kinds of services XServe is designed for isn't those markets. In those cases you really should be running a Sun or some custom Linux/BSD servers with the latest chips and a hell of a lot of memory. I believe that XServe is more designed for small businesses or for racks for internal use. (i.e. rendering farms, file servers, intranets, etc.)

        In those cases the ease of management will likely be a bigger factor than overall speed. If overall speed is that important you really need someone who is an expert in Linux or BSD, knows how to eck out every bit of speed, knows security up the yazoo, etc. And of course your department will have to pay for this guy. And that ends up being near $100,000 a year once you start including benefits etc. (Or more if you have several folks)

        For a more regular IT staff who doesn't want to spend that much time or effort XServe, like the equivalent offerings from DELL, Sun or Compact, is a nice server. As I said for ASP I still think Sun might be a better choice. But it really depends upon what you are doing.

      • by Jim McCoy ( 3961 ) on Tuesday October 29, 2002 @05:59PM (#4559660) Homepage
        A 10% performance difference is a wash as far as most sites are concerned, for a large site you will see this sort of a difference eaten up in your hourly traffic variance (e.g. you spec for the peak load, not sustained load) and if your bottleneck is at your servers then you have other problems to deal with. I can max out a reasonably sized internet uplink with a single, off-the-shelf PC. Given the cost of these boxes, it is _always_ going to be the case that your monthly bandwidth bill exceeds the cost of the servers needed to max out that connection. Think about that one for a few minutes and then get back to me on why you think a 10% performance difference is going to be a significant factor when it comes to purchasing decisions...

        When I was running YahooMail ops we used massive farms of FreeBSD boxes, not because it was the absolute best server PC OS when it came to performance (although at the time I think that it probably was) but because it was what we knew best. Filo was a BSD hacker and we had a collection of ops guys who knew that particular OS inside and out -- if there was a problem we could track it down and figure things out, we didn't have to start guessing or need to make an appeal to newsgroups or mailing lists for help. For a large site performance numbers like these are one factor, but it is not the only factor and is often not even the most important factor. Maintenance and management can often be a more important cost factor then raw performance, sometimes it is something as "trivial" as driver support (or even raw performance differences among various drivers and OS configuration options) or what the team doing the technical evaluation feels comfortable with using and supporting.
    • I agree with you wholeheartedly, but one small point - your learning Linux would not be cost effective for your current employer, it is most definitely cost effective for you as an admin (assuming that is in fact your line of work) :)
  • It is hard to see why OS X should be far behind Linux when it comes to server-side speed: OS X is based on a mature kernel with reasonably mature file systems.

    Where OS X seems behind Linux in terms of performance is memory footprint and graphics speed. In Moshe's server benchmarks, OS X used a lot more memory. Also, take a look at the memory footprint of the OS X display server and the OS X GUI applications--they are usually several times as large as comparable X11 functionality. And the raw graphics performance of the OS X display server is behind X11 in my experience (but do your own measurements if you don't believe me).

    • One thing to remember is that OSX is still using the HFS+ file system. The Byte article didn't mention is they were comparing it with the UFS. In either case Apple has new file systems coming down that might shake things up a bit in terms of both reliability and speed. Of course Linux has those now. But I think everyone agrees that XServe is nice for a first generation product. However as with most first generation products, think twice about being on the cutting edge. A better comparison might be a year from now when OSX is up to 10.3 with the equivalent XServe. Hopefully by then the new hardware based on the 970 will be out. Of course by the same measure the Linux/x86 world will also have moved on.
  • I'd like to see him repeat it, but with a few changes:

    a) Get the latest Jaguar
    b) Go to Apple and SuSE and get advice on tuning
    c) If it is available under SuSE, use gcc 3.1 for compiling

    Moshe admitted that there was probably alot of optimizations that he missed. I'd like to see them both tuned for speed and then compare them.

    • Just what I was thinking. I know you could do a lot of tweaking to get SuSe to run faster, but I bet there's not much you could do with OSX, seeing as it's running on Apple hardware.

      Still, an impressive showing for OSX. I think Apple's strength over the next several years will continue to be the desktop, but it looks like they might do well in the server market also.

      Oh yeah, I also think the Xserve is on of the most desirable pieces of hardware on the planet. They're purrty.

      • by Creepy ( 93888 ) on Tuesday October 29, 2002 @05:02PM (#4559374) Journal
        Actually, there is quite a bit you can do, since most of the actual web stuff is in the BSD layer. 10.1 is based on an older kernel, and 10.2 adds a lot to it. I'm not sure if all the additions really make it faster, but honestly, I don't know.

        Type this on a macOS X box:
        sysctl -a

        Some of these settings are sub-optimal for a server (at least with Jaguar, not necessarily OS X server). You could do something like this:
        sysctl -w kern.ipc.maxsockbuf=2097152
        sysctl -w net.inet.tcp.sendspace=262144

        to increase your TCP buffers, for instance. I know there are more areas for performance tuning, but I don't know them well. Search for sysctl on the web and you're bound to find some.
    • This story was originally posted on MacSlash, with a thread [macslash.org] of opinions on this as well.

      Biggest optimizations he missed: turning off Aqua! I kind of have to take this whole test with a grain of salt, you're not really doing justice to a spec test when you have two gui's running taking away performance from what your trying to test: the server.


      Since for the life of me I couldn't figure out how to shut down the GUI environment of OS X, I configured a simple VGA X server for Linux and started KDE, just to have a fair basis for comparison.


      Come on Moche, do a little research and login as "> console".
    • One other one:

      d) Try the tests while logged into the Mac in console mode, by typing

      >console"
      at the system login screen.

      As others have noted, a dormant window manager shouldn't consume any processor time, but if you can disable it on both machines that's a more accurate comparison than trying to get an X11/KDE combination to perform similarly to Aqua. That itself would be a long, complex, and ultimately probably not very interesting comparison to run -- suffice to say that if you can make both window servers fall out of the picture the comparison should be more accurate.

  • The slashdotted text (Score:3, Informative)

    by mblase ( 200735 ) on Tuesday October 29, 2002 @04:11PM (#4558946)
    (Sorry for some stray formatting of the tables; hopefully you can guess where the columns were)

    Comparing Apples and Penguins
    By Moshe Bar

    Last month, I described my romance with Mac OS X as a near-perfect environment for the desktop, and/or laptop. The harmonious combination of Apple GUI know-how with Unix (FreeBSD) for stability, security and efficiency are too sweet for geeks from all walks of life. I continue to use Apple laptops (I now have both the iBook and the Apple G4) for my writing, teaching and speaking activity. We received tons of reader's email here at Byte.com in response to that column. Too many to be named here rightly corrected me: Contrary to my first impression, there is indeed a package manager for OS X. It's called Fink and you can find it on www.sf.net/projects/fink. It also turned out that the Jaguar version I had received was a pre-release CD which contained only the 2.95 gcc compiler, though many reported that the 3.1 version of the same compiler was installed by default, as well. Apple quickly reacted by sending me the released version of Jaguar and, in fact, both compilers are present.

    As good as Mac OS X is for desktops and laptops, one wonders if the FreeBSD inside is not too restricted by the Apple jacket around it to also make for an efficient, secure and fast server OS. Apple is now busy convincing the world that Apples make also for excellent server appliances in the handy U1 format, thanks to OS X. That new product is called Apple Xserve. Many potential buyers are, however, asking themselves if OS X--given its recent introduction--is ready today to handle their critical apps.

    That's why I decided to take one of these sleek Xserve boxes and test run it both under OS X and under Linux. I was loaned an Xserve for a week by a geek friend of mine over at a very large ISP. That machine came with Dual 1Ghz PowerPC G4 and 1 GB of Ram. I installed OS X from scratch on it using the CDs that come along with the product. The resulting OS after the install has version 10.1.5. The included AGP 4X card with 64 MB of dedicated graphics RAM is a screamer. The dual CPUs in the system push out an impressive 15Gflops floating point power. Alas, apart from High Performance Clustering applications, relatively few people are going to take full advantage of it. The integer and memory bandwidth performance, however, is at least up to par with the latest IA32-based U1 servers out there. Obviously, I was not going to make use of the graphics card. I didn't bother trying to configure it under Linux because, after all, I tested this machine for server performance.

    I used the SuSE PowerPC Linux distribution for the second part of the test under Linux. Linux installed effortlessly and was happy to use all of the hardware found in the Xserve.

    The Test Environment

    Next to the obvious Apple Xserve, I set up 4 clients on the same 100mbit network, switched by the excellent Linksys 24port 1000/100/10 switch that powers most of my network in my home lab (for the LinkSys EF24G2M-10/100 EtherFast Dual Gigabit Switch 2-port 1000BaseTX see www.linksys.com).

    The 4 clients are all IBM Netfinity 5100 or 3000 machines running Linux 2.4.19 with my openMosix clustering extensions to automatically load-balance the requests thrown at the Xserve server. The four machines can easily saturate a fast server on a good switched network.

    Next, I set up exactly the same server environment both under Mac OS X and under Linux with the 2.4.19 kernel. I always made sure to use the same version of the server software both under OS X and Linux, each time re-compiling the binaries from source locally with the 2.95 gcc compiler, which is available on both platforms. The compiler itself was also locally re-compiled, taking all reasonable optimizations into consideration.

    Since for the life of me I couldn't figure out how to shut down the GUI environment of OS X, I configured a simple VGA X server for Linux and started KDE, just to have a fair basis for comparison.

    I ran tests against networking (Sendmail and MySQL tests), process build-up and tear-down (the cgi tests) and against the VMs (all tests combined, under memory shortage).

    For the static html benchmark, I wrote a simple html page just displaying "hello, world." For the dynamic pages, I wrote the CGI handler in Perl. The Perl used was 5.8.0 for both environments. Here is the sample cgi handler:

    package Apache::Bench;
    sub handler {
    my($r) = shift;
    $r->content_type('text/html');
    $r->send_http_header();
    $r->print('Hello, world ');
    200;
    }

    For the MySQL part, I set up a MySQL database with 30 million addresses generated by a simple filler Perl script before the benchmark. Then, I repeatedly let the clients run a series of transactions against it. I downloaded MySQL 3.23.52, skipping the harder-to-compile 4.0.x series, recompiled it locally under both OSes, then configured it with the following parameters:

    [mysqld]
    big-tables
    skip-locking
    skip-name-re solve
    skip-networking
    set-variable = max_allowed_packet=1M
    set-variable = thread_stack=128K
    set-variable = back_log=256
    set-variable = key_buffer=30M
    set-variable = table_cache=64
    set-variable = sort_buffer=5M
    set-variable = record_buffer=5M
    set-variable = max_connections=4000
    set-variable = join_buffer=5M
    skip-thread-priority

    For the mail handler, finally, all involved clients in the LAN were sending MIME-encoded attachments (I chose a small size of 8.5 KB to stress the MTA more than the network) to a 4.9 KB message. Sendmail was the standard 8.12.6 version available from the sendmail.org site, rebuilt for each OS. No special tuning was done and no anti-spamming measures were enabled. There was just one mail queue under both OS X and Linux, and the Sendmail-typical load-adaptive throttles were disabled to make use of the full bandwidth and system power. There is an excellent howto on enabling the native Sendmail 8.12.2 of OS X 10.1.5 here. I did however, as mentioned previously, compile my own Sendmail 8.12.6.

    Needless to say, setting up the server environment was considerably easier and faster. Linux, with all required sub servers, was ready in about 3 hours of work, whereas a long day passed before I had my OS X ready to go.

    For the web server tests, I downloaded Apache 2.0.39 and recompiled locally with the proper libraries. Just to avoid unnecessary lstat() system calls, I turned on FollowSymLinks and turned off SymLinksIfOwnerMatch. The SendBufferSize was increased to the size of the static page I used for this test. To make sure the page size is bigger than a TCP packet and also bigger than a virtual memory page, I made it 4050 bytes. Both OS X and Linux use 4 KB VM page sizes.

    I ran the following Perl program on the four clients each getting a different file, while I placed the virtual memory of the server under stress to cause the cache contents to be deleted as much as possible. Here is the Perl stress test program:

    #!/usr/bin/perl

    $counter = 0;
    $seconds = 2;
    $html = " ";
    $args = ("wget", "http://192.168.1.1/index1.html");
    $time1 = time;
    $check = $time1+$seconds;
    print "strtd at", time, "\n";
    while (time != $check) {
    $html = system(@args) or die "wget failed hard with $?";
    $counter = $counter +1;
    }
    $time2 = time;
    print "ended at", $time2, "\n";
    print "for ", $seconds, " seconds. \n\n";
    print "got ", $counter, " pages from server \n";
    [root@moshe1 temp]#

    In the end, I was quite pleased with the set-up. Again, all this is far easier and faster to do under Linux than under Mac OS X, but it can be done on both platforms given enough time.

    The Results

    Since this is not a scientific benchmark, I am quite sure your results will wary from mine. Also, note that this benchmark was done without prior consultations with either Apple or SuSE, so surely there are tons of tuning parameters for both operating systems that I simply didn't know about. Also, one should consider that the FreeBSD used in OS X is quite an old version (version 3.2, while FreeBSD just released 4.7), and that the Linux kernel has experienced a fantastic growth in performance over the last year, especially in the VM area.

    The results should therefore be understood as a general indication of the behavior of a particular OS when checked against the other, and not as a quality rating. All tests were run 10 times and I then averaged the results.

    Having said that, let's look the Apache results:

    URL OS X 10.1.5 Linux 2.4.19
    http://server/index.html 6127.2 reqs/second 7283.7 reqs/second
    http://server/cgi-bin/perl.cgi 624.1 reqs/second 703.5 reqs/second

    From these results one can assume the VM and network stack of Linux to be superior to OS X. It could also be that the page reclaiming algorithm is simply smarter in Linux than in OS X.

    For MySQL, I did much the same thing, with a Perl script running heavy SQL statements against the database. Here are the results:

    OS X Execution Times Operation Seconds
    alter_table_add 212
    alter_table_drop 118
    connect 2
    count 39
    count_on_key 721
    create+drop 4
    create_index 31
    insert 12
    order_by 187
    order_by_key 65
    select_distinct 38
    update_with_key 119
    Totals 1648
    Linux Execution Times
    Operation Seconds
    alter_table_add 197
    alter_table_drop 108
    connect 2
    count 15
    count_on_key 607
    create+drop 6
    create_index 22
    insert 8
    order_by 89
    order_by_key 91
    select_distinct 32
    update_with_key 76
    Totals 1253

    These results really surprised me. It seems OS X has a poor I/O subsystem as compared to the Linux subsystem.

    For the Sendmail results it is important to state that Procmail was unused on both systems. In order to let Sendmail wait less for I/Os, I also deleted the fsync() system call, which forces the full writing of each message on the file system. By deleting that system call from the sources, I let Sendmail defer the actual writing of the inode of each message to a later point in time. This is, obviously, against the RFC and should not be done in production-grade MTAs. Once you eliminate the fsync() call, more RAM will nicely scale up the number of emails being handled, which in turn better reflects the performance of I/O caching in the OS.

    OS X Linux
    Incoming Emails 816 mails/second 941 mails/second
    Mail Relaying 581 mails/second 609 mails/second

    Here again, Linux seems clearly superior to OS X for all VM-intensive operations.

    To go that extra mile, I then ran all these tests combined. Obviously all values were much lower and it is not the issue here to actually measure them. What, however, was much more interesting were values like load level, interrupts handled per seconds and context switches per second. For this final benchmark, I ran the Apache/MySQL/Sendmail tests at the same time, waited about 20 minutes after starting, recorded the results over a 2 hour period, and finally calculated the average:

    OS X Linux
    Average User-Land Runnable Processes 263 272
    Average Idle Percentage 0.3% 1.1%
    Average Context Switches (per second) NA 10212
    Average Free Pages NA 890
    Average Interrupts (per second) NA 9281
    Average Blocks Out (per second) NA 2008
    Average Load Level 27.1 26.2
    Average Swapped Set Size 421 MB 102 MB

    Sadly, I couldn't find any way to get decent system information from OS X. Things like interrupts or context switches per seconds are important indicators for a sysadmin. If there is no easy access to them (I am sure the kernel itself maintains these counters) how is the sysadmin supposed to see if the server is under- or over-utilized? This is a real shortcoming and Apple better introduce some way to monitor the system if they are serious about being in the server market.
    Conclusions

    Well, for a newcomer to the Unix market, I am actually surprised at the very decent results and stability of OS X. I experienced no crashes under both operating systems, which comes as no surprise to Linux users. For Mac users, however, this is by itself already a big improvement over previous operating systems for the Apple. The fact that OS X needs to improve in VM and I/O handling is understandable given its relatively young age. After all, Linux has had more than ten years to get where it is today, and even that is not much by OS standards.

    The Xserve's floating point performance is superior to many other solutions out there, and that alone makes it an excellent choice for clustering environments. But if all you are looking for is a server for your standard Internet or Intranet applications, then I see a problem in justifying the high price tag of the Xserve ($4000 for the configuration used in this test) for something that you can do faster, easier and cheaper on one of the many different products in the IA32 space.

    Moshe Bar is a systems administrator and OS researcher who started learning UNIX on a PDP-11 with AT&T UNIX Release 6, back in 1981. Moshe has a M.Sc and a Ph.D. in computer science and writes UNIX-related books.

    For more of Moshe's columns, visit the Serving With Linux Index Page.

    Copyright © 2002 CMP Media LLC, Privacy Policy
    Site comments: webmaster@byte.com

    • by merlyn ( 9918 ) on Tuesday October 29, 2002 @04:22PM (#4559036) Homepage Journal
      package Apache::Bench;
      sub handler {
      my($r) = shift;
      $r->content_type('text/html');
      $r->send_http_header();
      $r->print('Hello, world ');
      200;
      }
      Uh, that's not a "CGI handler". That's a mod_perl handler. And if that's the case, it shouldn't have been a 10-to-1 speed reduction over serving a static page.

      And a Perl script launching "wget", instead of just using LWP? Whuh? Huh?

      So, all these benchmarks are suspect. Beware. The author is either confused, or the editors mangled his message.

      • Sure, these benchmarks prove nothing and say very little, but what difference does it make if the perl code runs wget rather than using LWP, provided how it's done is consistent across testing platforms?

        If this was an attempt at testing the speed of perl, yeah, he really should've used LWP.
  • Why Darwin (Score:2, Interesting)

    This comparison brings up an interesting point. Darwin is open-source, and Linux is more mature and more quickly progressing.

    Why did Apple choose to go out and start a new kernel project when they could have just based OS X on the Linux kernel instead? They could have gained so much ground and lost so little. It's worked for so many other companies--why not Apple?

    • The kernel that the Darwin OS runs atop is far from new. The Mach kernel has been around for years, not sure of the exact dates, but almost if not as long as the Linux kernel.

      The decision to base Mac OS X on Darwin/NeXT was not just a decision about which direction to take with the kernel. There were plenty of business considerations a well, some of which centered around getting Steve back in da Apple crib.

      • Re:Why Darwin (Score:3, Informative)

        by RevAaron ( 125240 )
        Mach has been around years longer than Linux. Mach existed before this event, but in Oct. 1988 the first NeXT cube running NeXTSTEP on a 68030 was released. Every version of NeXTSTEP ran on Mach.
    • Re:Why Darwin (Score:3, Insightful)

      by jericho4.0 ( 565125 )
      I think you got it in your question. Linux is more quickly progressing. Basing the future of Apple on such a mecurial OS might not be the best thing to do.

      The BSD development process is slow and steady. It doesn't have 4 different threading models in the tree. It puts stability above new features. All good things for Apple.

      It would have been nice though.....

    • Re:Why Darwin (Score:3, Insightful)

      by sql*kitten ( 1359 )
      Why did Apple choose to go out and start a new kernel project when they could have just based OS X on the Linux kernel instead? They could have gained so much ground and lost so little. It's worked for so many other companies--why not Apple?

      Because NeXTStep was BSD-on-mach, and MacOS X on Xserve is essentially the next (forgive the pun) iteration of the NeXT Cube. (I am posting this from OmniWeb 2.0 running on NeXTStep 3.3 on an original Color Turbo).
    • Re:Why Darwin (Score:5, Informative)

      by megaduck ( 250895 ) <{dvarvel} {at} {hotmail.com}> on Tuesday October 29, 2002 @07:13PM (#4560257) Journal

      The Darwin kernel is based on Mach. While not a performance demon, Mach offers some very interesting advantages for Apple. Primarily, they have full rights to the code and can relicense it, whereas Linux would have bound them by the GPL. There's some technical advantages too, though.

      First of all, Mach was/is developed by Avi Tevanian. Avi is a old buddy of Steve Jobs and they've been working together since the NeXT days. Any questions about architecture? Ask the guy that wrote it, he's just down the hall.

      Secondly, the micro-kernelish nature of Mach makes Darwin (and OS X) a highly portable platform. With Motorola on the ropes, being able to shift platforms quickly is far more important than raw kernel speed. Darwin gives Apple hardware options, and options are a very good thing for Apple to have right now.

      Lastly, there's momentum. AFAIK, their kernel crew came over from NeXT, where they'd been using Mach since the eighties. Why bother learning the ins and outs of a new architecture, when you've already got something that works? Better to extend what you've already got.

      Darwin offers a pretty solid foundation for Apple. Moving to Linux would have taken a large effort for questionable gains.

  • by greygent ( 523713 ) on Tuesday October 29, 2002 @04:15PM (#4558972) Homepage
    Microsoft's Windows 2000 Server beat a Red Hat Linux* server in bandwidth tests, showing its clear superiority.

    * Red Hat Linux v4.2 used in tests.
  • Is this really a level playing field? I don't know much about PPC support in Linux but I do know that it's certainly not as slick on the desktop on a Mac as it is on a PC.

    Isn't testing OS X vs Linux on Apple hardware kind of giving OS X an unfair advantage as Apple know the ins and outs of their proprietary hardware so can throw in all kinds of optimizations?

    I'd be more interested to see Darwin/x86 go against Linux for web serving, especially if you throw in the Tux kernel module web server (good for performance).

  • by toupsie ( 88295 ) on Tuesday October 29, 2002 @04:17PM (#4558987) Homepage
    1) Moshe is using an old version of Mac OS X. The current version is 10.2 [apple.com].

    2) Moshe is not smart enough to boot Mac OS X into command line, "Since for the life of me I couldn't figure out how to shut down the GUI environment of OS X" -- Moshe "I can't use Google" Bar. Here's a tip Moshi, when the log on screen pops up, type ">console" [osxfaq.com] in the user line.

    3) MacSlash [macslash.org] has already dealt with this.

    • 2) Moshe is not smart enough to boot Mac OS X into command line

      I thought the point of the XServe was that you didn't need the command line? Why would being "smart" have anything to do with it anyway, the stuff in that tutorial you linked to is not at all obvious, and Apple has conditioned everybody to think that everything is always obvious on a Mac.

      If you don't need a GUI, then why bother with an XServe. And if you do, then why do you want to boot it into the command line?

  • by democritus ( 17634 )
    Okay folks, let's get this right. MacOS X is not derived from FreeBSD. It is derived from NextStep. MacOS X is a Mach microkernal with a persona that attemps to mimick BSD, FreeBSD in particular.


    Saying MacOS X is derived from FreeBSD is like saying that Windows XP is derived from System V because they both have POSIX compatibility layers. It's stupid and wrong.

  • MacSlash ran this... (Score:3, Informative)

    by gnuadam ( 612852 ) on Tuesday October 29, 2002 @04:17PM (#4558994) Journal
    ....you should check out their comments [macslash.org].
  • Umm, what? (Score:2, Insightful)

    by void* ( 20133 )
    From the /. article...
    Mac OS X Server 10.1.5 wasn't as far behind the curve as you might think. Performance might've been better if Moshe had Mac OS X Server 10.2, with its faster GUI...

    From the article itself..
    The included AGP 4X card with 64 MB of dedicated graphics RAM is a screamer...

    Ok, my question is this: It's a server-to-server comparison. What relevance does the speed of the GUI , and the performance of the graphics card, have? IMHO, the GUI should be shut down if at all possible for any server application.
  • by llamalicious ( 448215 ) on Tuesday October 29, 2002 @04:18PM (#4559000) Journal
    Not trolling, and I may have missed something, but the last time I checked, 4KB was 4096 bytes... thus, his 4050 byte static file still fits within a single VM page... yes?
  • Still very nice (Score:5, Informative)

    by mao che minh ( 611166 ) on Tuesday October 29, 2002 @04:28PM (#4559080) Journal
    These results, should they turn out to be reliable (which I believe that they are), speak volumes about the quality of MAC OS X. It is just slightly less efficient then Linux, yet still retaining a very high "ease of use factor". Not to mention it's amazing progess with the various components of it's GUI (Quartz - which creates two dimensional images, ATS, terrific OpenGL, the ability to save anything as a PDF, Aqua....) and easy to implement Cocoa and Carbon APIs.
  • optimizations (Score:2, Insightful)

    by sprytel ( 242051 )
    When you compile these applications, doesn't the source code contain platform-specific optimizations?

    It wouldn't surprise me that the implementation of Linux sendmail (for instance) has been tweaked to run faster than the OSX version.

    Obviously, the excuse "its not the OS, its the apps" holds little water... since the OS is only as good as what you run on it... but still...

  • by elliotj ( 519297 ) <slashdot@@@elliotjohnson...com> on Tuesday October 29, 2002 @04:37PM (#4559156) Homepage
    People buy OS X for different reasons than they do Linux. The fact that OS X has comparable performance is great news for the Mac platform.

    I love OS X for my desktop. I don't think I'd use it on a server because I can build a cheaper server using Linux to do everything OS X does and better. But from a desktop standpoint I find the GUI and applications a more pleasant experience than what's available for Linux.

    So the fact that I can run Apache, PERL, PHP, MySQL, GNU tools, BSD userland, AND Office X, Photoshop, RTCW, Jedi Knight etc on the same laptop makes me very happy. And it beats the hell out of dual-booting.

    So this is great for OS X. And great for Linux too I guess. Yay, everyone wins!
  • Logging in to Mac OS X as ">console" will switch to a textual login prompt.
  • by Anonymous Coward
    In an earlier article [byte.com], the wizard who wrote the above mentioned article, included some of his sample benchmarking code:
    #include <stdio.h>
    void main( void ){
    int x;
    long y;
    y = 28.2839281;
    x = 339829;
    y = x / y;
    printf("Content-Type: text/html\n\n");
    printf("Hello, world ");
    }
    along with the comment "Notice how I included some simple floating point arithmetic in the C program to make things just a tad tougher."
  • by Dog and Pony ( 521538 ) on Tuesday October 29, 2002 @04:44PM (#4559206)
    ... for a Mac. When it goes up to double performance, I'll consider it. For now, it is just so many pretty colors when running in as a server. In my personal opinion, that goes for the desktop too. But I'm sure many disagree, because "OS X has feature X!" Fine with me.
  • by Arcturax ( 454188 ) on Tuesday October 29, 2002 @04:44PM (#4559208)
    Our friends at Macslash have an article [macslash.org] about Apple recently jumping to the #5 server vendor, behind Sun Microsystems.

    In another MacSlash article, Why use Linux? [macslash.org] there is quite a lot of discussion about the merits of both Linux and Mac OS X.

    Both make rather interesting reading!
  • Idiotic comparison (Score:3, Insightful)

    by Brian Knotts ( 855 ) <bknottsNO@SPAMcascadeaccess.com> on Tuesday October 29, 2002 @04:47PM (#4559226)
    Who the heck buys an Xserve on which to run Linux?

    A more legitimate comparison would be a $4000 Xserve running OS X vs. $4000 worth of Linux on x86 hardware.

    But, we know what the results of that would be.

  • by gallir ( 171727 ) on Tuesday October 29, 2002 @04:48PM (#4559239) Homepage
    Something which I didn't find. Which filesystem did he used for the tests?

    OS X FS (HFS+) is not journaled. OTH, which FS in Linux? Ext3 is journaled and not very good for large directories without htree patch. ReiserFS is really fast for small files and creating new files. XFS very fast for large files...

    That's to say, the filesystem is possibly the bottleneck for those database and sandmail test. And don't forget the huge amount of apache log lines generated during the benchmarks.

    OTH, why did he disable fsync in sendmail? Any doubt in filesystem/cache performance on OS X?

    And.. for god sake, he didn't found how to disable the Aqua environment? And the console login whithout a password, what? One of my student found it in couple of seconds in Google.

    Cony!

  • by burgburgburg ( 574866 ) <splisken06 AT email DOT com> on Tuesday October 29, 2002 @04:52PM (#4559267)
    Gartner has a report [gartner.com] of the Worldwide server market for the 3Q 2002 (which grew by 3.1%). Though Apple makes up 1.2% of the server market, their sales of servers increased 273.8% (they were 0.4% 3Q 2001). Seems the XServe is making a positive impression.
  • Java performance... (Score:5, Informative)

    by wilburdg ( 178573 ) on Tuesday October 29, 2002 @04:53PM (#4559276)
    I ran the Scimark 2.0 [nist.gov] Java benchmarks on the same machine, running Yellow Dog Linux, kernel 2.4.19, versus Mac OS 10.2.

    Here are my results

    Yellow Dog 2.3: SciMark 2.0a

    Composite Score: 139.92947174097748
    FFT (1024): 123.98639890992068
    SOR (100x100): 166.2888365390105
    Monte Carlo : 11.87347214947242
    Sparse matmult (N=1000, nz=5000): 119.76608441786847
    LU (100x100): 277.7325666886154


    java.vendor: IBM Corporation
    java.version: 1.3.1
    os.arch: ppc
    os.name: Linux
    os.version: 2.4.20-0.7bsmp

    MacOS 10.2: SciMark 2.0a

    Composite Score: 65.55278911110278
    FFT (1024): 45.766180267285044
    SOR (100x100): 148.7766358092264
    Monte Carlo : 8.128496082717385
    Sparse matmult (N=1000, nz=5000): 43.78407287809933
    LU (100x100): 81.30856051818576

    java.vendor: Apple Computer, Inc.
    java.version: 1.3.1
    os.arch: ppc
    os.name: Mac OS X
    os.version: 10.2

    Machine:
    processor : 0
    cpu : 7455, altivec supported
    clock : 999MHz
    revision : 2.1 (pvr 8001 0201)

    processor : 1
    cpu : 7455, altivec supported
    clock : 999MHz
    revision : 2.1 (pvr 8001 0201)
    bogomips : 999.42
    total bogomips : 1998.84
    machine : PowerMac3,6
    motherboard : PowerMac3,6 MacRISC2 MacRISC Power Macintosh
    detected as : 129 (PowerMac G4 Windtunnel)
    pmac flags : 00000000
    L2 cache : 256K unified
    memory : 256MB
    pmac-generation : NewWorld

    Mem: 253776
  • Relevance ? (Score:3, Insightful)

    by vlad_petric ( 94134 ) on Tuesday October 29, 2002 @05:02PM (#4559364) Homepage
    What they did was "toy benchmarking". A benchmark is really supposed to be a program that is similar to what people run (to be a good indicator of performance). Is a "dynamic" page that outputs a constant string similar to any normal web application ?

    This is as relevant as the MIPS rating of a CPU (null, to be explicit). I'd really suggest them to take a look at some hardware reviews from gaming sites (e.g. firingsquad [firingsquad.com]) to learn some benchmarking methodology.

    And yes, pipes are much faster on Linux than on Windoze. Is it a relevant performance measurement ?

    The Raven

  • by Rui del-Negro ( 531098 ) on Tuesday October 29, 2002 @07:19PM (#4560327) Homepage
    This is a good test to see how efficient MacOS is. And personally, I'm a bit surprised that Linux "won"; after all, MacOS was supposedly written by people who know that hardware inside-out, and should be very well optimised for it.

    But this is not much of "MacOS vs. Linux" server benchmark, because Linux can run much faster on other plaforms. Why should you buy an Xserve to run Linux when you can get Intel / AMD / Transmeta systems that are faster and / or cheaper? The main (only?) reason to buy Apple hardware is the operating system. Which, judging from these reults, definitely has room for improvement.

    RMN
    ~~~

There are two ways to write error-free programs; only the third one works.

Working...