Slashdot Mirror
PPC Linux vs. Mac OS X Server: Linux Edges Out
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."
Mac OS X adds both local and remote GUI admin tools, which are quite good.
Donate free food here
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.
You are not required to run the GUI in Mac OS X.
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.
Uh, the XServe comes with OS X. You can buy a larger license if you need it, though.
Look, ma! I'm a karma whore
(Sorry for some stray formatting of the tables; hopefully you can guess where the columns were)
e solve
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-r
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
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.
--
The internet is the greatest source of biased information in the history of mankind.
FreeBSD PPC support is still wearing diapers, see the current status.
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" in the user line.
3) MacSlash has already dealt with this.
Strange women lying in ponds distributing swords is no basis for a system of government.
....you should check out their comments.
You say
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.
The more I learn about science, the more my faith in God increases.
Sorry, no it is not.
The XServe charges Hardware SCSI RAID prices and gives you software IDE RAID.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
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.
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.
d) Try the tests while logged into the Mac in console mode, by typing
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.
DO NOT LEAVE IT IS NOT REAL
Logging in to Mac OS X as ">console" will switch to a textual login prompt.
Our friends at Macslash have an article about Apple recently jumping to the #5 server vendor, behind Sun Microsystems.
In another MacSlash article, Why use Linux? there is quite a lot of discussion about the merits of both Linux and Mac OS X.
Both make rather interesting reading!
--Won't that be grand? Computers and the programs will start thinking and the people will stop. - Dr. Walter Gibbs
[ posted anonymously to avoid karma whoring ]
Comparing Apples and Penguins
(Comparing Apples and Penguins: Page 1 of 1 )
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-resolve
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.
Gartner has a report 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.
I ran the Scimark 2.0 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
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.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Bah. Even Sun sells a real server with SCSI for about as much as the Xserve.
Three words. Apple Remote Desktop.
A default install of Windows 2000 (Server or Pro) installs IIS. Meaning, if you don't do a custom install (which would be close 100% of non-admin-type installs), you're going to have IIS and all of its default subcomponents installed. You don't have to request anything.
Windows NT 4 (or lower) does not install IIS by default (in fact, it requires a separate CD, the NT Option Pack).
I don't know what the defaults for XP are. But, the point is, if you're talking about W2K, the parent post was absolutely NOT bullshit.
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.
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.
This
Many architectures allow booting this way. My Alphas can be booted without a video card using their serial ports. There are IP addressable boxes that connect to rack mounted servers using their serial ports. Through these boxes, you can boot the servers remotely, monitoring their progress over the serial port. Once a machine is up an running this way, it's then available over the network.
I'm pretty sure that Sun servers can be made to work the same way.
Guns don't kill people -- people kill people.
But the guns seem to help a bit. (apologies to Eddie Izzard)
Also too bad that he compiled everything with gcc 2.95 and not 3.2.
Just a Tuna in the Sea of Life
One part of the improvement in 10.2(.1), though not all of it, is that the majority of the system is built with gcc 3.1 instead of 2.9.5. According to most sources (including the gcc team themselves), 3.1-generated code is roughly 6% or so faster than 2.9.5-generated code. Apple has made quite a number of performance improvements in gcc as well, which fold into code built for 10.2.
Actually, you are incorrect. The I/O code is based on IOKit, not mach. And, most of the code was totally revamped in 10.2 to make it faster. In addition, when he makes comments about Linux's VM being more advanced, it is total BS. Mach VM was one of the original OSes to have a mature VM system. Most of the performance snags Moshe ran into are fixed in 10.2 and a lot more fixes are coming in SoftwareUpdates.