toggle

AAPL Stock: 497.67 ( -11.79 )

MacNN News

Review: Mac OS X limits server performance

updated 09:50 am EDT, Wed June 15, 2005

OS X server review

AnandTech has posted a lengthy . Lmbench was used to test MySQL performance and measure the bottlenecks at the Unix operating system and CPU level. "Mac OS X is incredibly slow, between 2 and 5(!) times slower, in creating new threads, as it doesn't use kernel threads, and has to go through extra layers (wrappers). No need to continue our search: the G5 might not be the fastest integer CPU on earth - its database performance is completely crippled by an asthmatic operating system that needs up to 5 times more time to handle and create threads."

by MacNN Staff

(20)

TAGS :

industry

Share the Article

Facebook Twitter Delious Slash Dot Digg

toggle

Comments

Jonas Maebe
Fresh-Faced Recruit

Joined: Jan 2002

0

06/15, 10:10am | report spam | close Reply |
Factual errors

Although I am curious why Mac OS X performed so badly in the database ad webserver tests, the reasons they give are wrong. Mac OS X most certainly does use kernel threads. In fact, every process under Mac OS X is nothing but a glorified Mach thread.

And the slowness is also not due the fact that they use Mach, because they are not using it like a traditional microkernel (where every service runs in a separate memory space), but everything runs in one single address space (even the Mach and BSD personalities run in the same address space).

Some more detailed comments can be found at http://ridiculousfish.com/blog/?p=17

TwinFeats
Fresh-Faced Recruit

Joined: Feb 1999

0

06/15, 10:21am | report spam | close Reply |
Thread creation

I've been a developer a long, long time, and I found the reading of this article quite amusing! Let's first accept the premise that the performance issues are indeed due to thread creation. This is the "Doctor, doctor - it hurts when I do this" syndrome. I haven't created threads willy-nilly in a application in at least 15 years, it's just not a good idea. Any system resource that required overhead to create you should try to only create once, then reuse - it's call pooling. Databases do it all the time with connection pooling. The interpretation of the test results is flawed because the test application was not measuring anything other than poor application design.

elvis2000
Dedicated MacNNer

Joined: Jan 2003

0

06/15, 10:24am | report spam | close Reply |
Old news

Interesting how MacNN posts this only *after* Apple's Intel announcement. This is old news.

Ben Lawson
Fresh-Faced Recruit

Joined: Jul 2002

0

06/15, 10:27am | report spam | close Reply |
Debunked last week

This article was discussed in other places last week. It seems that the testers don't understand some important characteristics of how Mac OS X operates. They have inadvertently(?) created an artificial test condition that actually highlights their lack of insight...

Intelligently designed server applications run very well on Mac OS X. Badly designed ones... don't.

marcelol
Fresh-Faced Recruit

Joined: Apr 2005

0

06/15, 10:40am | report spam | close Reply |
Just as expected

ore drivel from the reviewer crowd that thinks that they can just walk up, throw something down onto a box, and say "go". Sure, on the desktop, for the user, stuff just runs ( I love being a Mac person again and being able to say that, after 20 years on PC's. Hey...I have a household to support ), but on a server, there are always things that need to be tuned to the environment they're being run in. Has anyone looked at how many different things you can ( and usually HAVE to ) do to Oracle to get best performance out of it ( no matter what platform you're running on ) ?

What possible brain-deficiency related thing made them think that their little test case even made sense ? And frankly, I STILL question what even GAVE THEM the idea that they were prepared for this ? Has Anandtech EVER done any sort of review of anything else Mac related ( I don't think so, but I could be wrong on that ) ?

But I digress, I think they need to go back to school, and rethink their approach. Come back to us after you've actually thought the assignment through boys.

cyngus
Fresh-Faced Recruit

Joined: Apr 1999

0

06/15, 11:00am | report spam | close Reply |
Poor Article

This one was posted on Slashdot a while ago. The reviewer's methodology is horrible, and he does nothing to try to isolate the source of the performance difference, even on the small array of micro tests he does. The reviewer also does not fully understand the Mac OS threading model and his understanding of what an OS is, is poor at best.

eddd
Fresh-Faced Recruit

Joined: Dec 2001

0

06/15, 11:14am | report spam | close Reply |
Re: Just as expected

Anandtech is generally quite positive when it comes to the Mac, and is nearly always fair. Anand Shimpi keeps a Mac runing as one of his personal machines, and continually shows admiration and respect for the machine and OS.

That said, he's only a kid. And although extremely bright, he's not the last word in computing (although treated as such by many PC folk).

giantmike
Mac Enthusiast

Joined: May 1999

0

06/15, 12:24pm | report spam | close Reply |
Re: marcelol

For a list of Mac articles at Anandtech, see this link: http://www.anandtech.com/mac/

wadesworld
Grizzled Veteran

Joined: Apr 2001

0

06/15, 12:38pm | report spam | close Reply |
Results

Let's not put our head-in-the-sand. The fact that you can't get good performance out of the box *is* a problem.

But the only people that can address it is the MySQL and Apache developers.

LordJohnWhorfin
Fresh-Faced Recruit

Joined: Aug 2002

0

06/15, 12:55pm | report spam | close Reply |
Let's face it

Performance sucks. There is absolutely no reason why MySQL performance should be any worse out of the box than it is on Linux. The old saw "it wasn't optimized for OSX" is just a load of c***. The fact that microkernel architectures are a performance sink has been known for years (google Linus vs. Tanenbaum if you don't believe me). OSX is currently carrying the baggage of its NeXT origin. It's time for Apple to admit there's a problem, and FIX it. When they start delivering Intel-based machines the lackluster performance of the machines is going to become a very serious issue, because it's going to be trivial to benchmark OS performance (if you can run OSX, Linux, FreeBSD and Windows on the same machine, and run MySQL on all environments, it's easy to rate OS performance objectively).

ishabalov
Fresh-Faced Recruit

Joined: Jun 2005

0

06/15, 01:21pm | report spam | close Reply |
It's true

This article from IBM seems to confirm Anandtech results:

http://www-106.ibm.com/developerworks/linux/library/l-ydlg5.html?ca=dgr-mw01LinxOnG5%22

sehix
Fresh-Faced Recruit

Joined: Sep 2000

0

06/15, 02:43pm | report spam | close Reply |
Re: Let's face it

Performance is going to suck...if you use a compiler that isn't what ships with the system and can't autovectorize, can't even generate AltiVec code, use a version of MySQL that does fork() at random times, unlike the version of MySQL that ships with OS X Server, etc.

And "objective performance rating" isn't all that useful if you don't understand how a particular OS/application combination work, especially if different platform do things slightly differently.

resuna
Fresh-Faced Recruit

Joined: Jan 2005

0

06/15, 03:44pm | report spam | close Reply |
Linus vs Tannenbaum

The fact that microkernel architectures are a performance sink has been known for years (google Linus vs. Tanenbaum if you don't believe me).

Both Linus and Tannenbaum were arguing past each other in that debate, and Linus still doesn't seem to understand microkernels.

Minix was a bad example of a microkernel from the point of view of performance because its servers were deliberately simple to make them easier to understand... it's an educational OS, the fact that it was actually useful was serendipity.

Mach is a bad example of a microkernel because it uses a heavyweight mechanism (the VM system) as the basis for IPC, which means it doesn't have the option of getting a performance boost from running cooperating servers in the same address space. That's why OS X uses the BSD kernel, a monolithic kernel, to provide so many of the services.

A well designed microkernel like QNX has very fast thread creation and message passing, and I've pointed this out to Linus on multiple occasions. His latest response was that QNX is not a commercial success as a consumer operating system so it's irrelevant... if microkernels were so effective QNX would have "made it".

QNX is a real-time OS in the process control industry, and the only people trying to make it a consumer OS were a bunch of Amiga fans who didn't actually pay Quantum for their work. So the fact that it didn't "make it" is merely a reflection of the fact that it never tried.

jhorvatic
Fresh-Faced Recruit

Joined: Apr 2005

0

06/15, 06:11pm | report spam | close Reply |
Lacking a server platform

Apple has a server platform it's called Xserve to the nimrod writer of this article. And it seems that the Xserve platform has done quite well for itself at many big companies with no performance issues.

Apocalypse
Dedicated MacNNer

Joined: Jun 2000

0

06/15, 07:41pm | report spam | close Reply |
Re: Linus vs Tannenbaum

Umm, OS X _does_ use MACH, and not the BSD kernel.

It does, however, use it as a monolithic kernel by loading kexts into the kernel address space instead of launching servers. This is a bad design but it gives them some performance benefits. The problem is that MACH's IPC does more than they need it to for day-to-day operation (ie: it has network transparency and other rather heavy features). Still, it is fast compared to writing to a socket and has less kernel memory overhead.

A light-weight microkernel like L4, QNX, or vxWorks makes for a really fast system. MACH is decent and we get really fast thread creation so it is something.

That, however, is not the debate at hand.

It sounds as though the article is wrong if it says that "OS X sucks because it doesn't use kernel threads" since that doesn't even make sense. How can the kernel not use kernel threads?

If MySQL is using some odd user-space thread library then they should fix it to use the native threads. If this is a library that ships with the system then Apple should probably make it use kernel threads (although their might be reasons why they don't - maybe some apps want to control their own threads, for some reason).

Detrius
Professional Poster

Joined: Apr 2001

0

06/15, 09:08pm | report spam | close Reply |
Ridiculous Fish?

Did any of you read the Ridiculous Fish article referenced by the first post? The bottom line is that OS X is slower because it flushes the hard drive buffers correctly. Linux is faster because it doesn't force the hard drive buffers to write to disk. MySQL is faster because a very important data integrity feature is not present on Linux.

vlad1leen
Fresh-Faced Recruit

Joined: Jun 2005

0

06/16, 02:27am | report spam | close Reply |
Apache test is wrong

They Claim; Mac OS X 250 req/s, Linux 3800 req/s using; ab -n 100000 -c 150 http://localhost/ (so they run the test tool on the cpu itself)

Turn's out that if you run ab on Mac OS X with -n 100000, execution stalls from time to time, and so the it reports a lower then expected req/s

So I run on a dual 2.7 with a clean install of Mac OS X Tiger; ab -n 1000 -c 150 http://localhost/ -> 5900 req/s ab -n 10000 -c 150 http://localhost/ -> 8500 req/s (this one stall's sometimes) ab -n 100000 -c 150 http://localhost/ -> 250 req/s (always stalls) The drop off is due to ab and not to the web server, in fact the web server is idle and if you use another machine on the network to test the web server still under test, it's still fast and responsive.

So knowing that ab on Mac OS X was the problem when run with -n 100000, I run it from a linux box; ab -n 100000 -c 150 http://ip_address_server/ -> 5800 req/s So instead of being 10 times slower, Mac OS X server is around 1.5 to 2 times faster on that test against the Linux box. (66 Threads running very fast an not showing any problems in speed ;-)

If you want to run the test on a client machine, turn on the webserver, go to the terminal and type; ab -n 1000 -c 150 http://localhost/ Make sure you have a valid index.html file, Mac OS X tries to answer in your language so before running test go to; /Library/WebServer/Documents/ and rename index.html.en to index.html (otherwise you would see low req/s ... Depending on HW you should see 500 req/s up to around 2000 req/s, remember de server is tuned for performance that's why you won't see the numbers I mentioned unless you have a tiger server.

The slowness of mysql can be better understood if you go to; http://ridiculousfish.com/blog/

I will do some java server benchmarking with 800 threads, but as far as I can see it runs as fast as a dual Xeon 3.2 GHz ...

So Client yes, Server most certain! Look at, at the bottom you can see that my results are in the same trend; http://www.apple.com/xserve/performance.html

resuna
Fresh-Faced Recruit

Joined: Jan 2005

0

06/16, 04:25am | report spam | close Reply |
Mach, BSD, threads.

Apocalypse: OS X uses Mach *AND* the BSD kernel.

Mach is NOT a complete kernel. It provides little more than memory management, scheduling, and interprocess communication. It requires servers to provide all other operating system function. In OS X, and in fact in ALL production Mach-based systems I'm aware of, a traditional BSD kernel running as a server UNDER Mach is what provides almost all other OS services. Drivers are divided between traditional UNIX style drivers in the BSD kernel, Mach-based loadable drivers, and in some cases drivers that are loaded separately but run as part of the traditional kernel.

This is the "single server" approach. It takes advantage of Mach's modularity while avoiding having to perform multiple context switches between separate servers for every system call. If Mach were a properly designed microkernel, it would be possible to run multiple servers in the same address space and perform message passing between them without the overhead of a MMU context switch. This would not be "bad design", it would simply be an implementation detail that could be changed simply by changing the way each specific service was launched.

Lites, Tru64 UNIX, and Mac OS X are all BSD-based single server designs. The only Mach-based system I know of that isn't a single-server design is GNU's ill-fated Hurd.

Avoiding MMU context switches, by the way, is why applications may use user-space threads as well as or instead of kernel threads. If the threads are being created to implement a design that is inherently concurrent, rather than to coordinate with asynchronous events, it can be a LOT more efficient to use user-space threads instead of kernel threads because it reduces thread switching time to the same order of magnitude as a subroutine call.

blidd
Fresh-Faced Recruit

Joined: Sep 2003

0

06/16, 06:02am | report spam | close Reply |
Reading this threath

I very confusing and not understandable for Joe average. Problem is that Jo avarages looks at test like that and takes it at face value. Might be the reason why arstechnica has those long reviews;-)

thoughton
Fresh-Faced Recruit

Joined: Nov 2003

0

06/16, 08:33am | report spam | close Reply |
How is this news?

I read this article almost two weeks ago, along with everyone else. Why is MacNN reporting this as "news" now?

Show More Comments

Login Here

toggle

Network Headlines

02/15	Sony completes Ericsson stake buyout...
02/15	Apple upgrades iBookstore with screenshots...
02/15	Congress asks Apple to answer questions...
02/15	FLA head describes Foxconn plants as...
02/15	Apple asks to sue bankrupt Kodak in...

Show All

02/15	Sony completes Ericsson stake buyout...
02/15	Congress asks Apple to answer questions...
02/15	FLA head describes Foxconn plants as...
02/15	Apple asks to sue bankrupt Kodak in...
02/15	Apple voluntarily pulls iPads from...

Show All

02/15	Apple upgrades iBookstore with screenshots...
02/15	Congress asks Apple to answer questions...
02/14	Apple attempting to disrupt Siri hacks...
02/14	Readability iOS app delayed, Android...
02/13	Apple launches 2012 back-to-school...

Show All

02/15	Monster iCarPlay Wireless FM Transmitter...
02/14	Refurb. 16GB iPhone 4, now only $259...
02/13	Refurb. Flip UltraHD Pocket Digital...
02/10	$380 off refurbished 2.8GHz Mac Pro...
02/09	iHome Dual Alarm Clock for Apple iPod...

Show All

toggle

Review: Mac OS X limits server performance

updated 09:50 am EDT, Wed June 15, 2005

OS X server review

Factual errors

Thread creation

Old news

Debunked last week

Just as expected

Poor Article

Re: Just as expected

Re: marcelol

Results

Let's face it

It's true

Re: Let's face it

Linus vs Tannenbaum

Lacking a server platform

Re: Linus vs Tannenbaum

Ridiculous Fish?

Apache test is wrong

Mach, BSD, threads.

Reading this threath

How is this news?

Login Here

Register for our weekly email newsletter:

Connect tools:

Subscribe

to our RSS

Follow us

on Twitter

10 Most Read

10 Most Discussed

MacNN Marketplace

Review: Mac OS X limits server performance

updated 09:50 am EDT, Wed June 15, 2005

OS X server review

Related Articles

Recent Articles

Factual errors

Thread creation

Old news

Debunked last week

Just as expected

Poor Article

Re: Just as expected

Re: marcelol

Results

Let's face it

It's true

Re: Let's face it

Linus vs Tannenbaum

Lacking a server platform

Re: Linus vs Tannenbaum

Ridiculous Fish?

Apache test is wrong

Mach, BSD, threads.

Reading this threath

How is this news?

Login Here

Register for our weekly email newsletter:

Connect tools:

Subscribe

to our RSS

Follow us

on Twitter

10 Most Read

10 Most Discussed

MacNN Marketplace