Slashdot Mirror
FreeBSD and Linux Comparative Apache benchmarks
An anonymous fan wrote in to send us some benchmarks that attempt
to compare
FreeBSD and Linux
and normal web tasks like CGI, Flat HTML and mod_perl.
A little thin on the details, but not surprising results.
anybody ?
The server is deceased. Doesn't even respond to pings. No HINFO entry in the DNS record, so it's impossible to guess what OS it was running before it died.
I'm _guessing_ that you installed FreeBSD 3.2 and then installed Netscape (maybe from the ports collection). The problem with this scenario is that 3.2 doesn't by default include a.out compatibility libraries and netscape is currently distributed as an a.out binary. You can remedy this by installing the compat22 distribution or enabling linux emulation and using the linux version of netscape :).
/usr/src/sys if you install the source as part of the install process).
As for getting the sources, look at Obtaining FreeBSD. As another poster has already mentioned, the kernel is in the ssys portion of the source distribution (or in
And stop with the "I assume freebsd won because that isn't supprising". Can someone please post the numbers? Was anyone able to see the page at all?
We can get on to the Linux/BSD flame war . . . Let the games begin. :)
"As to other distros, I didn't like the feel of Redhat and didn't want to pay money for free software anyway. "
Uhh..RedHat is just as free as Slackware, Debian,
SuSE and the rest.
"Besides all that, FreeBSD has complete Linux emulation, so any proggie that will run on Linus' OS will run on any FBSD system. "
Oh, really, does that include VMWare? If so,
I might give FBSD a shot!
Do any of the BSD's have SMP support? Not that I need it on my PB 200 Mhz but just wondering.
perl.pattern.net is running Apache/1.3.6 (Unix) mod_perl/1.19 on Linux
(from netcraft.com)
BSD and Linux are brothers at heart. BSD has just ended up with the unfortunate potential of cooption by Microsoft, hereas Linux (or more specifically, GLP) is immunized. Of course, we will not know the outcome of all of this for some time yet. Even thu GLP is 'immunized', it is not yet proven to be invunerable. There is no telling how much damage MS can do with their money and their lawyers, but I am certain it is considerable.
Uh, where have you been? I thought it was pretty much the group decision was that all benchmarks are a bit funny.
GLP GLP GLP.
Don't know what it is but it sounds really funny.
Hey let's change it to GLP/Linux and watch Stallman hit the f*cking roof!
Perhaps you meant GPL, no. But I like GLP so much I'll never go back.
I know linux really sucks at multiple ethernet cards but I wonder what the new kernel will bring in light of this. I thought Linus got rid of that nasty spin lock back in the 2.0 days. Remember that freebsd can not bind ethernet cards to cpu's yet either so a uni machine under bsd will not make that much of a difference expect under high loads assuming if 1 cpu is overloaded processing the tcp/ip stack and would have to thread part of it to another cpu. Your connection will always kill performance way over cpu contention. Perhaps I am wrong.
I just assumed that even a 100mps would love the cpu pretty empty.
Yeah, he should have run Linux, instead of that dorky FreeBSD. Linux performs better in the real world (read: under heavy fire from Slashdot), even though all other OS'es perform better in benchmarks
vfork is really a fork in all modern unices. Fork now uses a copy-on-write technique. Parent and child use the same process memory but they both have read access to it. When one tries to write to their shared memory, it gets a page fault and the kernel copies the memory somewhere else so that page (usually 4k) is no longer shared.
Just a dexlexic moment. Sorry
I copied their test.html document and tried it on my test machine with 4x200MHz PPro CPUs and Linux 2.2.5... I got a higher number for a single user (which compares to their benchmark), and higher still with more concurrent users:
Users Requests/second
1: 1112
2: 1594
4: 1864
Their Linux output peaked at 996 requests/second, on a PIII no less... I wonder if they used persistent connections. Their test script (test.sh) runs the executable "ab" which they didn't describe in the document.
They didn't say either what percentage of CPU was claimed by the client... on a uniprocessor that can be significant, since the CPU must context-switch to handle both the client and server code.
I don't have FreeBSD loaded or I would've tried that too...
This is one of the points that BSD fans keep bringing up. "You can run Linux (and SCO) software on BSD, so why use Linux". Yet I have never seen the issue of performance brought up anywhere. Great BSD can run Linux software, the question is can it run it as well as Linux, and if not how much worse.
We've seen that xBSD makes a better servers than Linux and that isn't currently disputed, however I would like to see some other performance numbers, numbers relevant to me choosing between BSD and Linux on my desktop. Does anybody know where I can find that?
Nope, vfork() really is different in BSD, and it really is faster. (because it doesn't have to recreate all the memory structures of the old process in the new process)
Linux 2.2 now has vfork() as well-- but I don't know whether Apache uses vfork() on any OS. (if it did, it would most likely only use it for CGI)
No, FreeBSD uses a small sh, while most Linux distributions use the full bash for /bin/sh (with all the bloat).
.. unless you are pointing out design decisions in the loop back interface.
It used to be that BSD systems would trigger an immediate task switch with each packet sent through the loopback interface.
Linux instead used a timer tick driven loopback queue, where multiple packets queue in the loopback interface. The sending process generally gets its entire scheduling period. Trivial benchmarks showed higher latency on Linux than BSD(causing much glee in the OSS BSD community -- part of their "higher network performance" claim), but real life performance is much improved due to fewer task switches and better cache locality.
Most BSD projects now use something akin to the Linux loopback approach, but of course they are tuned differently.
Just one more example of BSD Unix being very well designed for a VAX 750, but slower to adapt to modern system tradeoffs.
Ohh, to mitigate that potential flamebait: I would expect Apache to perform identically on typical systems (non-SMP, non-RAID).
The NetBSD docs have a good page on why vfork is still useful.
http://www.applix.com/appware/linux/index.htm
According to Applix, they will be porting and shipping RSN due to demand, so you should soon have a native version.
I think the FreeBSD folks mentioned that their TCP/IP stack isn't threaded either.
> Does *BSD have software RAID?
Yes, I believe there is a software RAID module for FreeBSD. I don't know if it comes with the standard system or if it's something you'll end up downloading from elsewhere.
> Would you not expect that setting up a web server with at least software RAID would allow for
> faster responses, especially if there were databases on the same box on RAID devices?
Not necessarily. If the entire dataset fits into the RAM cache anyway, there won't be any disk activity for most web serving events. Databases + RAID sounds like a better application, but most web sites don't use databases.
> I suppose the reason this was not tested is because, IMHO, RedHat screwed up and included a
> non-integrated version of the RAID code in their kernels.
RedHat included a working version of software RAID. AFAIK, the RAID code in the plain 2.2 tree is not as recent/stable as the code shipped with RedHat.
> Ever wonder why RedHat has not posted a 2.2.10 kernel?
Maybe because there are still some filesystem-corrupting bugs in it?
> I guess we'll just have to wait for mingo to create the patch for 2.2.10.
Ingo is working on a new version of RAID for Linux 2.3, the last I heard.
> Maybe they should use vfork for CGI on systems that have it. I think this would significantly
:)
> speed up CGI on BSDs.
Probably not. CGI is slow anyway unless the CGI is very small; otherwise the time it takes for a CGI program to initialize and start up kills you. The time it takes to fork is quite small overall.
Now, if you want to do benchmarks of
/* cgi.c */
main()
{
fputs("Hello!", stdout);
exit(0);
}
then you may well get great benchmark results on vfork() versus fork()
> It is under Linux. Other systems implement vfork in different ways
It is under Linux 2.0. Linux 2.2 and above has a true vfork(), which was really implemented for emulation of other OSes, and not for the performance benefits...
I know q3test and almost all Quake servers can run on FreeBSD since they don't need svgalib, but I was wondering if there is a way to run the client for Quake I and II on FreeBSD?
:)
Sorry if the question is a little "off topic" but I didn't found any document on the net about this subject. I would really appreciate if someone can point me out an url that explain how (if it's possible) to do it.
This is exactly right. A half-dozen or so 3-5 rated comments with little or no -1 comments will get you an automatic +2 on every post (at least, at one point it did for me, guess I'll see if that's true anymore since I haven't posted in weeks).
If there are known deficiencies in Linux, why weren't they fixed... yesterday? Linux gets all the press, but FreeBSD puts up the numbers.
It is always nice to see the responses invalidating simple tests in one way or another. "Here is why this particular test isn't exactly right, and why Linux is looking bad even though it isn't..."
I think we know there are problems. But fixing them perhaps brings no glory. Who is doing the dirty work? The bells and whistles always seem to move quickly (.. glory of being a part of them) but the trench work always seems to move so very, very slowly. Or is this just my imagination?
Perhaps my unsophisticated brain just can't understand this. I'm just a simple caveman lawyer. (huh?) But while Linux tries to lead the way into the mass consumer market, or while it tries to handle more and more processors, it seems to leave behind simple fundamentals. Being #1 means you must be #1 in all areas, ever changing, and ever advancing areas. Nothing can be left behind.
> Most sites that I go to DO have a database, or at least I assume so. /. certainly does.
:)
And the performance of slashdot is certainly quite stellar, I think we'd all agree..
> The "portal" sites must (to store your user preferences and also the stories/articles that are
> displayed based on your login ID). I assume Freshmeat does. I would think that other "news"
> sites that list abstracts of stories do
Yes, these sites use databases to construct the pages. However, in the case of real heavy-traffic sites, database performance is just too slow. So what really does 99% of the serving is a cache that stores copies of dynamically generated pages.
Oh, and probably >75% of the actual network traffic is images, which can be stored in one big directory and served up by a simple web server.
> What RedHat included was not what I considered production quality (even though I'm using it now)
Agreed, but I believe the RAID code in the official kernel is worse, not better.
> > Maybe because there are still some filesystem-corrupting bugs in it?
> There were in 2.2.9, but AFAIK 2.2.10 is stable.
At least Alan Cox is still talking about hunting down some sort of fs-corruption bugs in it.
> To include "custom" (meaning not part of the official kernel as released by Linus et.al.)
> kernel patches, even if publically available, is irresponsible for a company like RedHat IF they
> don't take the responsibility to keep those patches (even if they didn't create the original)
> up to date so that it can be applied to the production kernel as new releases come out.
People wanted a Linux distribution based on 2.2 and that is what RedHat put out. Personally, I think that waiting until the fall or so for most of the issues in 2.2 to settle out is the best idea.
> Last I heard he was also supposed to be working on the patches against the 2.2 series kernel also.
> At least I and a bunch of other people on the linux-raid list hope so...
Waiting for 2.4 will probably be a better idea, because it will be a lot faster than 2.2 anyway (especially w/SMP), and will likely include LVM support and other stuff that will interact with RAID in interesting ways.
It's back up now, but I guess his linux servers just couldn't handle the load... :)
>> Could it be a WinLose server?
Close. It's linux. And it's back up (probably will collapse under the load again later on),.
My only software problem with FreeBSD is getting Applix to work. Applix is the only Linux commercial application I run that does not seem to have a FreeBSD version
Doesn't the emulator work? Try 'man linux' on the FreeBSD box. I haven't setup the emulator either so I can't tell you if Applix runs or not but I found this on Deja(news).com which seems to indicate that it does. This post seems to say RealPlayer G2 works under the emulator as well!
the Linux TCP/IP stack needs work.
Not really. On the same hardware, Linux and FreeBSD are pretty much equal with netperf. Linux is slow with memory management and disk cache, among other things. NT benchmarked faster than Linux because of it's multithreaded tcp stack. On a single processor system, a multithreaded stack won't help that much.
As far as the client loads slowing down the server... On this test, the FreeBSD clients must be doing more work because they are recieving more data. Had they been moved to another system, the server could have run even faster! The programs he is using are mainstream OSS apps which have been available on both platforms for years. Had there been an oppurtunity for optimization in either platform, I'm sure it would have been taken.
Running "ab -c 10 -k -t 15 http://server/index.html" over a 100 mbps net, with FreeBSD (4.0-current) serving I get 954 requests/sec but with Linux (2.2.10) serving I get 308 requests/sec. The systems have different hardware though. One of these days I will have to try both on the same box.
As far as the client code, it is the same on both platforms (comparing apples and apples) so the only way the code would run faster is if the specific OS is faster. Plus with FreeBSD's clients processing more requests, they must be doing more work which proves FreeBSD is even faster! (of course I won't try to seriously argue that position).
I wouldn't use these statistics to compare C to Perl. I just created a quick and dirty benchmark of the sample perl code versus not using the CGI module, instead just printing the header as they did in the C code. The results were:
Perl w/ CGI module = 247 seconds
Perl w/o CGI module = 43 seconds
BTW, I didn't do anything with the CGI module in the above tests, I just included if for the sake of the compile.
Have a look here. http://www.cybernet.com/~mtaylor/q3ahowto.html
It would be interesting to see if FreeBSD is faster than Linux at running Q3test.
Yahoo and most large companies use BSD!!! not Linux
Thanks for the numbers. I am supprised linux did this well. I laughed after looking at these results expecting freebsd to be somehting like 300% faster but after readint mindcraft and zdfud I kind of look at linux benchmarks with my teeth grinned as I read them expecting something truly awefull. I like linux but it has seemed to make alot of comapnies and people jealous because if its overnight sucess and popularity popularity. Like Thompsons comments and Jesse Berst's and sco's ceo and many hardcore unix folks and so on. Alot of these companies like sco and Sun are members of linux international so they can convert linux users but deep inside and outside as well they want to eat linux for breakfast.
Anyway I am supprised that linux only lost during raw http bytes a sec. and it didnt even lose by that much. It also seems that linux does realyl well with cgi scripts. Remember the germans ct magazine benchmark with linux vs NT and linux with 1 cpu outperformed NT with 4 when it came to cgi scripts.
Anyways thanks and moderators boost the original comment higher becuase the slashdot effect killed the web site and I thought it was insightfull.
Linus just added a cpu to ethernet card binding utility to the latest 2.3 kernel so when 2.4 comes out I would love to see how well bsd and NT can compete agaisnt linux. The only thing really hurting linux is the poor single threaded tcp/ip stack. I belive this is why alot of freebsd folks say there Os is better. After this new kernel is released I wonder if there will be any advantage left in traditional unix's or will linux finally be ready for prime time in the unix server arnea with the big boys.
You know some people use their BSD or linux boxes for things other than web servers. Which one runs matlab or scilab faster?
It just that most of you plebs don't ever muck around with the dev kernels. There is some quite significant work going on in the TCP/IP stack on 2.3 right now, much of it due to misfeatures exposed in the Mindcraft benchmarks. I'm thinking Cox needs to incorporate network caching on the PCI bus using PCI S3 video cards. They were doing that with gigabit ATM a while back, but I bet you'd see a performance gain for just about any network type.
The server went down with a power outage. It's a linux box (for those who are curious) with enough memory and CPU time to burn. If anything gets slashdot'd, it would be the pipe...
It's up now.
Chip
Does anyone have any idea why the difference? Is the Linux TCP/IP stack slower? Also, why did Linux come out ahead on just Perl and C CGI scripts?
Well, netscape is hardly one of the basics of a server operating system, but it's always worked fine for the FreeBSD machines I've used it on. I trust you're using the version from the ports collection?
But linux will grow faster and more streamlined.
As will the BSDs.
ALso does anyone know where i can get the BSD kernel source? Like the latest version.
It's in /usr/src/sys (or at least it should be if you installed everything correctly). The entire sources for the system live in /usr/src. You can get the most current sources by using cvsup to update your local source trees from the FreeBSD cvsup servers. Some example cvsup files live in /usr/share/examples/cvsup. Check out stable-supfile and ports-supfile.
Hmm? Netscape doesn't work on FreeBSD? Funny, I downloaded the FreeBSD version from ftp.netscape.com and it worked fine.
My only software problem with FreeBSD is getting Applix to work. Applix is the only Linux commercial application I run that does not seem to have a FreeBSD version. Well, RealPlay too... v3 is kinda old...
My only real gripe with FreeBSD is that it's not as clean and "transparent" as OpenBSD. It's starting to look as cluttered as Linux.
-E
Send mail here if you want to reach me.
Posted by !ErrorBookmarkNotDefined:
Now what OS was used to serve this?
Mirrors?
-----------------------------
Computers are useless. They can only give answers.
I was hoping to read that story, but, alas the site seems borked. Has it been /.'ed this early?
Heh
OUT...
#941
I'd really like to know a) how you come to this conculsion and b) where your evidence is.
,hacker Perl another Just)'
Not that I don't believe you - I just hate seing blind advocacy without any real figures behind it. You've made a blanket statement "[freeBSD], despite having a faster TCP/IP stack, linux is faster" - but I'm unconvinced. However I do run Linux and not *bsd because there are still apps that are Linux specific (e.g. Oracle and Sybase, both of which I need to run) - and I don't fancy playing about in any compatibility modes for that stuff since it's critical to me.
perl -e 'print scalar reverse q(\)-:
Matt. Want XML + Apache + Stylesheets? Get AxKit.
The point though was to benchmark the speed of the web environments (i.e. CGI, mod_perl, php etc) not the different OS's. The different OS's were just thrown in there to see if that made a significant difference. It didn't, and I'm not sure why someone posted this to slashdot except as flamebait.
,hacker Perl another Just)'
The mod_perl group is hoping to do some more extensive benchmarking to look at the speed differences in longer scripts in the different languages too - the "hello world" example is only really a valid comparison between different ways of using Perl - not of different languages - for that you need a more complex test.
Matt.
perl -e 'print scalar reverse q(\)-:
Matt. Want XML + Apache + Stylesheets? Get AxKit.
No offense, but why was your posting instantly uprated to a "2" score?
If your posts are often upgraded, then you start defaulting to higher numbers; if they're consistently downgraded, then you'll start defaulting to zero score.
So, it's probably that he writes a lot of good posts. Either that or he does have a secret admirer with moderator status. :-)
dylan_-
--
Igor Presnyakov stole my hat
and found it was running Apache 1.3.6 w/ mod_perl 1.19 and Linux
jaraxle
I wonder who compiled apache, and with what compiler, and what flags ;-) Compilers do matter, as I just learned myself today, I wonder how much they would affect apaches preformance.
Those links are just a couple of errors...
And as for the PRE tag, some people decided it would be funny to use it to make lines 80 screens wide, etc... so it was disabled.
Whoops.. The links are good if you remove the /.-imposed spaces it appears.
just installed freeBSD I didnt like it... I wanted to see whitch was more solid freeBSD seemed nice but A
:)
/etc/rc.conf and set lpd_enable="YES". You may find you get better results. ;)
/. before, "FreeBSD, Linux, it's like blondes and brunettes, I like them both". Let's not forget with these entertaining holy wars we're all on the same UNIX side. On the other hand, these little family squables can be extremely entertaining and productive, don't you think?
;)
lot of the basics just wouldnt work like *netscape* which hurt my feelings..
That's interesting, because I tried FreeBSD out of desperation in searching for a UNIX that would work well without much initial effort from me (I had not yet learned much about Unix, but that has changed largely since then). I found it to be far superior to Linux in that respect. I had been using Slackware for several months the year before I installed FreeBSD. I didn't like it much. As to other distros, I didn't like the feel of Redhat and didn't want to pay money for free software anyway.
FreeBSD was extremely easy to install. The ports tree system and Handbook on the homepage flattened the slope of the initial learning curve, and was remarkably rock stable. The centralized nature of FreeBSD is unbeatable. One also gets the advantage of benefiting from the many years of clean, efficient, intelligent coding done at Berkley University by all of those PhDs. Your tax dollars at work, take advantage of it.
Besides all that, FreeBSD has complete Linux emulation, so any proggie that will run on Linus' OS will run on any FBSD system.
As to the basics such as netscape not working (I never had any difficulty with any of it) perhaps you are going about things wrong? Did you try and install it from the ports, or did you try and install the Linux distrobution? If you tried the ports, that is curious. If a Linux distro, it may take some tinkering to set up right. If you are trying to run a Linux binary, did you make certain that your Linux emulation was working properly? go into
Maybe BSD is faster now.
It was always my impression that Linux was catching up to FreeBSD. After all, as the web page says, it has "The power to serve". They're not being overconfident, FreeBSD was built to be server first, workstation second. But as I type this note on my FreeBSD 3.2Release system running on a Toshiba Satellite laptop, I can't help but remember the article one or two months ago on Daemon News called The Power to...Work? which discussed something I had learned to my joy six months ago...that FreeBSD is a superb choice for a workstation. I'm a graduate student doing computational chemistry, and I most of the same stuff on my laptop that everyone else in the office does on their SGIs.
But I wouldn't trade it for my linux box anyday..
That's too bad. But if you want to stick with the penguin with the fat butt, it's your call. It's okay, too, because FreeBSD can just ride piggy-back on Linux's success. And like the sig I've seen here on
Happy hacking, Linux people We FreeBSD folk will just occassionally poke you fat penguin folk in your huge butts with our tridents every now and again so you don't get too comfortable in that oh so hot spotlight.
Uhh..RedHat is just as free as Slackware, Debian, SuSE and the rest.
Well, when I was learning about Linux, I had bought a nice thick book about it, which included a Slackware CD, a RedHat CD and a Caldera Lite CD. From what I was able to gather from reading the material presented in the book at the time , neither of the latter was available as a free version. That was not what I wanted, I wanted a free (like free beer) UNIX, and Slackware seemed to fit the category. I never even heard of SUSE or Debian until this year.
A year later, when I decided to try FreeBSD, my ether was set up, and I understood networking a little better. It was, by far, the easiest to install over the network. If one just does a little digging on the homepage, say looking at the link entitled, "Getting FreeBSD" or reading the brief section further down called, "Easy to Install", one can learn how to install the OS with extreme ease and simplicity.
"database stuff" usually don't fork either, for performance reasons.
Either database files are opened by some database library (that can stay in memory as long as the client code is), or, client-server style, the queries are sent to a database daemon that is also persistent (multiforked with processes pool or multithreaded, shouldn't matter).
I think that the figures are so close that you will choose FreeBSD or Linux over the other depending on others criteria (apps, available hardware, staff knowledge, ...)
Personally, I've use SunOS 4 and hated the interface; I much prefer Solaris (ie, SVR4) which linux is closer, so linux is my preferred choice. YMMV, of course.
Let the holy war commence :)
--
"There are lies, damned lies, and benchmarks". Yes, all benchmarks are a 'bit funny', but this one is worse than usual; whoever conducted it is a bit naive about how to perform benchmarks.
--
In addition, the load will be affected by the script running on the same machine.
Using a bourne shell to conduct tests is not something I would view as particularly useful; perl would have been better, since it could compile itself to begin with to be more efficient (ie, faster). Also, this will give one concurrent test at a time; not particularly relevant in real-world situations.In conclusion, basing FreeBSD performance vs linux performance using these figures is lunacy.
--
When you get a cumulative score >n (what number? does anybody know), all your comments start at 2 points. Check his userinfo -- he's posted 55 comments, and all of them are at 2 points. In addition, there is no moderator comment, so it has to be an automatic thing.
/* Steinar */
(This comment is of course GPLed.)
While I'm all for holding back the OS holy wars, please remember that we're NOT all just "Against Microsoft."
Characterizing this movement as solely an anti-Microsoft sentiment devalues our platforms. After all, we're not OS/2, MacOS, or any of the non-free Unices. We're free, open software, and that's what's important.
--Joe--
Program Intellivision!
Oh, really, does that include VMWare?
Why yes, it does. My workstation is a P200MMX, so I didn't run VMWare for very long, but it ran properly.
Perhaps the reason it takes longer to spawn a process has to do with the ABI "emulation". (There is another post on how this works.)
From what I understand, rather than having fixed syscall #s, freebsd (and probably open/netbsd) load an array of syscalls, which differs between the various supported ABIs.
Has anyone benchmarked this sort of thing? It would stand to reason that the extra overhead associated with supporting different ABIs would make spawning a process (or at least loading an executable) more expensive.
(Please correct me if I am wrong... I really am curious about this.)
--Rob
There's an entry in the FOLDOC for "slashdot effect"--see http://foldoc.doc.ic.ac.uk.
-rozzin.
/.'ed to hell and back. ;)
Anyone got a mirror? I'd really like to see these numbers.
Are the FreeBSD guys are pounding on us for being slow?
This sig is false.
There's two questions here. First, how fast is it, and second, how complete is it?
To answer the first question -- FreeBSD's Linux emulation is as fast as FreeBSD is.
"Emulation" is the wrong choice of word really. To put it in fairly non-technical terms for a moment. When you run a binary on a FreeBSD (or Linux system, or other Unix system for that matter) the "image activator" examines the file to determine what to do with it.
Most Unices have an image activator that does one of two things. If the first two characters are "#!" then it recognises it as being a shell script, and does the right thing. Otherwise it loads the binary, fixes up any shared object references, and runs it as normal.
FreeBSD's image activator does something slightly different. As you know, program make lots of system calls, and in the binary these calls are specified as numbers rather than names (i.e., open(2) might be number 57). FreeBSD's image activator pulls in an array that maps these numbers to the actual FreeBSD system calls.
For FreeBSD native binaries these are one and the same thing.
If the image activator sees this is a Linux binary, it pulls in a different array. This might map the open(2) call from it's Linux number (34 say) to the FreeBSD number (57 -- remember, these numbers are hypothetical).
That's all. So this is not really emulation at all, but simply implementation of a different Application Binary Interface.
More more detail about this is available at the FreeBSD Handbook Linux section.
Because there's no emulation to slow the process down, resource-intensive Linux binaries benefit from FreeBSD's better handling of heavy loads. This is the main reason for the claim "Better Linux than Linux" that you'll hear bandied about.
Before you ask, no, I don't know of any benchmarks, because I don't know of anyone that's taken the time to do it. If someone in the UK wants to throw a spare hard disk my way, I'd be happy to do it.
As to the second question -- despite what some of the more enthusiastic FreeBSD supporters here have said (and my address is nik@FreeBSD.org, so you can expect some bias) FreeBSD's Linux emulation is not perfect. Some (very much lesser used) system calls are not properly mapped, and some have no direct FreeBSD equivalent. But the vast majority of software works with no problems (that includes things like StarOffice, WordPerfect, and Oracle, to name three of the big heavyweights).
In addition, a couple of people have just joined the ranks of the FreeBSD committers expressly to work on FreeBSD's Linux emulation, so it looks as if the final wrinkles will be ironed out sooner rather than later.
Hope that helps.
N
Benchmarking using a real network would make sense if you were benchmarking an entire system, including the network cards and drivers. This didn't seem to be a "this server configuration vs. that server configuration", but rather a "FreeBSD vs. Linux" and "static vs. mod_perl vs. CGI" benchmark.
If you want to see a FreeBSD vs. Linux benchmark, using a real network will skew the results in favour of whichever has the better driver for the given card.
For example, if you benchmarked with an Intel Etherexpress 10/100(B|+) card, the results would probably be tilted in FreeBSD's favour, as that driver in FreeBSD is extremely clean and efficient. OTOH, if you benchmarked with a DEC Tulip-based card, the results would be tilted towards Linux, because the Tulip is maintained much more actively in Linux than in FreeBSD. I'm not talking about a guaranteed win for one OS or the other, but it would have an effect on the result.
This doesn't invalidate your concerns about running a benchmark on localhost. The loopback device in one OS still might be better optimized in one OS, but using a real network device has that problem too.
The client load certainly interferes with testing the system as if it were a real web server. But if it's just some arbitrary FreeBSD vs. Linux test, there's nothing wrong with adding client load, as long as it's the same load on both systems. Such a test is valid, but not interesting, as it doesn't represent a real-world application.
I'd say the "Static vs. mod_perl vs. CGI binary vs. CGI perl script" data is interesting, as all other factors were the same between those tests. I certainly found it educational... I knew what order they would come in, but was not sure exactly what the gaps would be.
Also FreeBSD uses a "real" sh while Linux just uses a scaled down version of bash. The lack of bloat in FreeBSD's sh could give it an extra speed bonus.
I have questions about the RAID support in Linux and if this could not have been used to obtain better results. Specifically, I'm talking about software raid and not hardware RAID solutions.
:-)
Does *BSD have software RAID? How does it compare to Linux's software RAID? Would you not expect that setting up a web server with at least software RAID would allow for faster responses, especially if there were databases on the same box on RAID devices?
I suppose the reason this was not tested is because, IMHO, RedHat screwed up and included a non-integrated version of the RAID code in their kernels. Ever wonder why RedHat has not posted a 2.2.10 kernel? If you loaded up RedHat 6.0 and created software RAID filesystems you can't upgrade because you can't patch the later kernels with the new raid code.
Yes, I follow linux-raid and there is supposed to be a way you can apply the patch to later kernels, ignore the rejects, manually make a few changes in some files, and supposedly be "safe" to run your new-style RAID disks. However, even though I have a DAT drive and can backup everything I'm not taking that chance on a "production" kernel. If it was 2.3.x I would not be complaining. I guess we'll just have to wait for mingo to create the patch for 2.2.10.
Yes, this is a troll, but I'm hopeing that it will put a fire under someone's but at RedHat to provide some assistance. No, I don't plan on making any contributions and fixing the code myself. If I tried, you would probably find your disks fried beyond repair because I don't know the code base yet. (But the way it's going I may have a good chance of getting up to speed before a patch comes out
Anyway, that's why they could not have tested software RAID even if they wanted to. Thanks for letting me flame, downgrade me if you must...
Ignore my signature please :P
--
I just installed freeBSD I didnt like it... I wanted to see whitch was more solid freeBSD seemed nice but A lot of the basics just wouldnt work like *netscape* which hurt my feelings.. But it looked pretty solid. But I wouldn't trade it for my linux box anyday.. Maybe BSD is faster now. Or at least that is what myth tells us. But linux will grow faster and more streamlined.
ALso does anyone know where i can get the BSD kernel source? Like the latest version. I looked on freebsd.org I didnt find anything but I didnt look to hard..
thanks...
I *am* curious as to what system it *was* running :)
Ummm ok I don't have any proof per se. Really I've never poked through all the source code, or done performance tests myself, however here's how I got to my conclusions -
Most people say FreeBSD has a faster TCP-IP stack. I've seen (no I can't cite anyone) posts saying this and generally I'll believe it. A few technical posts have convinced me.
FreeBSD faster on static-html, and mod_perl routines. Linux faster (by a small margin) on cgi stuff. What's different between these methods? Well the cgi stuff involves creating a new process. The others don't. Thus I think FreeBSD is slower to create a new proccess than linux.
This is how I got to my conclusions. I will admit to a slight error, or confusion. I said "linux is faster". Editorially that should probably have been hacked off or worded to something like "linux is faster once the TCP/IP stack benefits run out for FreeBSD". Again though that might not be the right phrase. I mean that in this case linux is faster for forked proccesses. Err something. Now I might just be confusing myself.
-cpd
OK my understanding is that any cgi program when run is actually a new program, and that mod_perl is run from within the web server. My simple translation - cgi's fork mod_prel & static don't fork. From the numbers FreeBSD seems faster at anything that the web server can do. Outside of that FreeBSD slows down, despite having a faster TCP/IP stack, linux is faster. Most websites use some form of database stuff, therefore it makes more sense to use linux for those sites (or so it does to me).
Anyways just my thoughts.
-cpd
perl.pattern.net is running Apache/1.3.6 (Unix) mod_perl/1.19 on Linux
Remembering your name in the morning is already a good start...
I wonder whether it was running Linux or FreeBSD? :-)
Netcraft says: perl.pattern.net is running Apache/1.3.6 (Unix) mod_perl/1.19 on Linux
I think there is still a gap between linux and the big boys. When people buy million dollar multi proc machines, they want an OS that can handle them. Please don't anybody say Beowulf because it doesn't run on the same computers. I think OS's like Irix and Aix will be around for a while.
There is some technical reason that I have forgotten, but it is apparently true.
-- Reverend Vryl
I may take some time to write a generic web load simulation suite so that these things can be done in a standardized way.
However, I am pleased to see that people are looking into BSD vs Linux performance. Linux needs to not get complacent, and BSD is an ideal prod in that direction. NT just can't provide the level of competition necessary to keep us lean and mean.
Starting nmap V. 2.2-BETA4 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) ... good.
Host (206.107.112.9) appears to be up
Initiating TCP connect() scan against (206.107.112.9)
Adding TCP port 685 (state Open).
Adding TCP port 113 (state Open).
Adding TCP port 514 (state Open).
Adding TCP port 695 (state Open).
Adding TCP port 21 (state Open).
Adding TCP port 690 (state Open).
Adding TCP port 22 (state Open).
Adding TCP port 664 (state Open).
Adding TCP port 1024 (state Open).
Adding TCP port 109 (state Open).
Adding TCP port 23 (state Open).
Adding TCP port 110 (state Open).
Adding TCP port 25 (state Open).
Adding TCP port 515 (state Open).
Adding TCP port 111 (state Open).
Adding TCP port 513 (state Open).
Adding TCP port 80 (state Open).
The TCP connect scan took 5 seconds to scan 1483 ports.
For OSScan assuming that port 21 is open and port 30328 is closed and neither are firewalled
Interesting ports on (206.107.112.9):
Port State Protocol Service
21 open tcp ftp
22 open tcp ssh
23 open tcp telnet
25 open tcp smtp
80 open tcp http
109 open tcp pop-2
110 open tcp pop-3
111 open tcp sunrpc
113 open tcp auth
513 open tcp login
514 open tcp shell
515 open tcp printer
664 open tcp unknown
685 open tcp unknown
690 open tcp unknown
695 open tcp unknown
1024 open tcp unknown
TCP Sequence Prediction: Class=random positive increments
Difficulty=4317652 (Good luck!)
Sequence numbers: D75785A4 D6DE6B3D D771D9C5 D78FDB55 D78E8360 D6E6CD12
Remote operating system guess: Linux 2.1.122 - 2.1.132; 2.2.0-pre1 - 2.2.2
Nmap run completed -- 1 IP address (1 host up) scanned in 6 seconds
> ERROR: IEXPLORE caused an invalid page fault in module MSCONV97.DLL at 0137:01212d19. Stack dumped:
This won't format quite right since Slashdot doesn't accept the "pre" tag (why?)...
HTTPD Web Application Env Hits/s Operating Sys. Chip Session Client HTTP/x By
----- ------------------- ------ -------------- ---- ------- ------ ------ --
*apache 1.3.6 static html 996.41 Linux 2.2.10 PIII-500 no ab 1.0 ct
*apache 1.3.6 mod_perl 518.24 Linux 2.2.10 PIII-500 no ab 1.0 ct
*apache 1.3.6 C/C++ cgi executable 210.19 Linux 2.2.10 PIII-500 no ab 1.0 ct
*apache 1.3.6 perl cgi 7.22 Linux 2.2.10 PIII-500 no ab 1.0 ct
*apache 1.3.6 static html 1183.64 FreeBSD 3.2 PIII-500 no ab 1.0 ct
*apache 1.3.6 mod_perl 568.28 FreeBSD 3.2 PIII-500 no ab 1.0 ct
*apache 1.3.6 C/C++ cgi executable 154.94 FreeBSD 3.2 PIII-500 no ab 1.0 ct
*apache 1.3.6 perl cgi 6.94 FreeBSD 3.2 PIII-500 no ab 1.0 ct
As extracted from this post on the mod_perl mailing list which summarizes all the results of everyone so far.
Here is the author's summary:
Subject: Benchmarks
Author: Chip Turner
Date: Sun, 4 Jul 1999 19:40:44 -0400 (EDT)
As promised, I've run some benchmarks under Linux and FreeBSD comparing
Perl CGI, C CGI, flat html, and mod_perl. I've tried to duplicate the
methodology used by the benchmarks posted here in the past. The results
were fairly interesting. If anything can be concluded, it is that Perl
CGI is dead for serious web development. It's just way, way, way too
slow. Apache::Regostry can improve this (and I've not tested how much of
an effect it would have), but 7 requests per second compared to about 550
requests per second with mod_perl is _quite_ a significant gap.
Another interesting result is that for non-CGI requests, FreeBSD seems to
be about 10% faster than Linux in the mod_perl and flat html tests.
The info, including httpd.conf, the test script, and other info is
available at http://perl.pattern.net/bench/. Any feedback is definitely
welcome. If there is much interest, I can add an Apache::Registry version
of bench.cgi to the test, as well as a C Hello World Apache module.
(perl.pattern.net is a new DNS entry, so it might not have propogated yet.
Hopefully it will within a few hours.)
Chip
as found here.
Could it be a WinLose server?
--- Linux or FreeBSD, it's like blondes or brunettes. I like both. ---
This looks like a pretty even race.
No winner, no loser in this configuration
I think my old tagline summarises it pretty well.
//Gunnar
--- Linux or FreeBSD, it's like blondes or brunettes. I like both. ---
Well, it looks like they got their server back up, because I was able to get a look at their page. Here are the results:
http://localhost/
Linux - 766.11
FreeBSD - 860.76
http://localhost/index.html
Linux - 996.41
FreeBSD - 1183.64
http://localhost/mp/
Linux - 518.24
FreeBSD - 568.28
http://localhost/cgi-bin/bench
Linux - 210.19
FreeBSD - 154.94
http://localhost/cgi-bin/bench.cgi
Linux - 7.22
FreeBSD - 6.94
. when in danger or in doubt, run in circles scream and shout --Robert Heinlein
The results are about what I'd expect--the Linux TCP/IP stack needs work.
But really, benchmarking using loopback??? I hardly expect a loopback driver to be optimized. The client loads interfere with the serving. And ther's no network driver or interrupt loads.
I would have been much more impressed if two boxen with 100baseTX cards had been connected with a crossover cable. It has plenty of bandwidth. Network benchmarks should be done on a network!
-- Robert
I think the Slash.dot publicity has killed the poor guys server :)
...Student, Artist, Techie - Geek *
Mong.
* Paul Madley
*...Slacker, Artist, Techie - Geek *
Remember: Nothing is Cool.
By the look of it, it was Win3.1 :)
...Student, Artist, Techie - Geek *
Mong.
* Paul Madley
*...Slacker, Artist, Techie - Geek *
Remember: Nothing is Cool.
Steven,
;)
...Student, Artist, Techie - Geek *
No offense, but why was your posting instantly uprated to a "2" score?
Hmm, somebody likes you
Mong.
* Paul Madley
*...Slacker, Artist, Techie - Geek *
Remember: Nothing is Cool.