Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Unix Operating Systems Software

FreeBSD and Linux Comparative Apache benchmarks 119

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.
This discussion has been archived. No new comments can be posted.

FreeBSD and Linux comparative Apache benchmarks

Comments Filter:
  • by Anonymous Coward
    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.
  • by Anonymous Coward
    You know some people use their BSD or linux boxes for things other than web servers. Which one runs matlab or scilab faster?
  • by Anonymous Coward
    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
  • It's not whether, it's when! Things are moving along well.
  • 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?
  • I don't know whether Apache uses vfork() on any OS.

    I didn't get any matches for it when I grepped Apache's source tree..

  • 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.

    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
  • by gavinhall ( 33 )
    Posted by !ErrorBookmarkNotDefined:

    Now what OS was used to serve this?
    Mirrors?

    -----------------------------
    Computers are useless. They can only give answers.
  • Posted by _DogShu_:

    FreeBSD won static, and Linux won CGI.
  • I was hoping to read that story, but, alas the site seems borked. Has it been /.'ed this early?




    Heh

    OUT...

  • I'd really like to know a) how you come to this conculsion and b) where your evidence is.

    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(\)-: ,hacker Perl another Just)'
  • 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.

    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(\)-: ,hacker Perl another Just)'

  • 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_-


    --

  • 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 [current.nu], as I just learned myself today, I wonder how much they would affect apaches preformance.
  • 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..


    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 /etc/rc.conf and set lpd_enable="YES". You may find you get better results. ;)

    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 [daemonnews.org] called The Power to...Work? [daemonnews.org] 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 /. 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?

    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.

  • >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).
    "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, ...)

  • Plain fork() is really fast on Linux.
    I'm not sure vfork() syscall was added for performance reason, but rather because of people requests (ease the porting for apps that use vfork(), and simple enough to implement that Linus bothered implementing it :) ).
    I could be wrong, I saw the discussing some months ago...
  • Does Apache use vfork() if it is available?
  • It is under Linux. Other systems implement vfork in different ways, that's why I asked. I am wondering if that is what caused Linux to be faster on the CGI scripts and C programs.
  • Maybe they should use vfork for CGI on systems that have it. I think this would significantly speed up CGI on BSDs.
  • My guess is that FreeBSD won; it's known for having a better TCP stack than linux (a fact the linux developers have acknowledged).

    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 :)
    --

  • FreeBSD's advantages come into play since its TCP stack is threaded; linux still uses some heavy locking in the kernel hurting TCP performance. Since this was (a) a uniprocessor machine and (b) the requests were coming in sequentially, linux didn't lose out by much. This benchmark isn't particularly useful in that regard since it doesn't reflect real world situations.
    --
  • "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.
    --
  • It's not just the "multiple ethernet cards", it's the "multiple connections". As I understand it, once the kernel is handling one bit of TCP, several functions in the kernel get locked out, hurting performance. In other words, the granularity of the locks isn't small enough.

    Work is ongoing in this in light of the redone Mindcraft tests which showed that, even with tuning, a powerful quad processor unit was better running NT than linux for file sharing. Uptime, reliablity and CGI performance are a different matter entirely, however.
    --

  • Well, a few flaws are fairly obvious in the benchmarks:
    All tests were conducted through the local loopback adapter.
    This kind of makes the tests rather non-applicable to real-world scenarios. It will also negate any differences in device drivers and bring in new problems with differences in loopback drivers.

    In addition, the load will be affected by the script running on the same machine.

    The tests were conducted with this script.
    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.
    --

  • by Sesse ( 5616 )
    Perhaps we need a definition of the Slashdot effect soon :-) Does the server have to be down? What is the limit? 3 bytes per second?

    (The server didn't work for me either, in case that's unclear.)

    /* Steinar */
  • 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 */
  • On this basis though, somebody could write low-quality messages frequently, and then get a higher score automatically.

    The 1 point you get for being a registered user doesn't count, I guess. Only if some moderator(s) gives you 2 (or 3, or 4, or 5) points, they begin to accumulate.

    Note that this also goes the opposite way -- write too many 0 or -1 messages, and you'll start at 0 instead of 1. (Idea: Get a new account :-) )

    /* Steinar */
  • When you get a cumulative score >n (what number? does anybody know), all your comments start at 2 points.

    Let me guess, it would be something like:

    • Anonymous Coward - 0
    • Mostly Anonymous - 2
    • Poor - 8
    • Average - 24
    • Above Average - 44
    • Competent - 130
    • Dangerous - 512
    • Deadly - 2560
    • Elite - 6400
  • Let's stop with these stupid, internal os holy wars. We're all in the same boat (be it BSD,Linux hell even HURD) and all against micro$oft.

    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

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

  • In this case the server is probably keeping up ...
    We stuffed their pipe ;)
  • There's an entry in the FOLDOC for "slashdot effect"--see http://foldoc.doc.ic.ac.uk [ic.ac.uk].
  • /.'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?
  • On FreeBSD's Linux emulation, an AC wrote:
    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.

    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 [freebsd.org].

    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.

  • Uh, he is running linux. Besides, it's
    probably not the server that died, but that his
    pipe is being filled (as stated above).
  • 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...
  • > 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.


    Most sites that I go to DO have a database, or at least I assume so. /. certainly does. 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 (do you really think someone custom makes each and every news story, or they just store the text/page in a database?) Certainly financial sites do that store news for companies and chat areas.

    In fact, I can't think of a web site that should not use a database that I would regularly visit. If they don't, then the content can't change that much and it's not worth "regularly" visiting. For those types of sites (static, not changing regularly) you're probably better of using Netscape's or IE's ability to check for changes and notify you than constantly pulling it up manually.

    > 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.


    What RedHat included was not what I considered production quality (even though I'm using it now). I HAD a RAID setup and when I installed ended up deleting the partitions and remaking the RAID volumes because there was no "warning" that RedHat needed the special upgrade force command to migrate the disks. Plus, they give you no way of installing on a RAID device anyway, so why did they feel the need to include a "non-standard" kernel anyway (you have to install on a "regular" partition, drop to single user, unmount almost everything, setup your RAID devices, copy over the data, and reboot in order to get "standard" directories like /usr and /var on a RAID with RedHat 6.0) If they were interested in giving their users the heads up on the much improved RAID support they should have included the standard RAID drivers that come with the kernel and put a note in to let their customers make the decision to use a non-integrated patch or not.

    > Ever wonder why RedHat has not posted a 2.2.10 kernel?

    Maybe because there are still some filesystem-corrupting bugs in it?


    There were in 2.2.9, but AFAIK 2.2.10 is stable. AND it fixes several security bugs which I can't protect against because of my RAID situation. 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.



    > 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.


    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...
  • Got to remember, can't stare blind on performance figures. There are other things to consider too, functionality etc. Especially when they both were so close!..

    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...
  • How can you say linux is more streamlined?!?!?

    there are how many linux distros out there?

    IMHO... linux is a sucsessful hack job... but please don't get me wrong, i support all free/open source unix oses. Some are better than others in certain things (don't even get me started on OpenBSD and crypto... nothing else can even touch it)

    Let's stop with these stupid, internal os holy wars. We're all in the same boat (be it BSD,Linux hell even HURD) and all against micro$oft.

    Btw- yes FreeBSD has SMP and i believe Net and OpenBSD have it as well.
  • I *am* curious as to what system it *was* running :)
  • But of course...BSDi does, though commercial; FreeBSD has had support since 3.0 (see http://www.freebsd.org/~fsmp/SMP/SMP.html [freebsd.org]); and it appears as though NetBSD is working on it.
  • > I just installed freeBSD I didnt like it...

    I'm sorry...

    > 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..

    That's odd...I've used both the FreeBSD and Linux versions of Netscape here with out problems.

    > ALso does anyone know where i can get the BSD kernel source?

    If you are looking for an online reference, check out http://www.freebsd.org/cgi/cvsweb.cgi [freebsd.org]. If you want to download the source, you can get 'ssys.*' from ftp://ftp.cdrom.com/pub/FreeBSD/3. 2-RELEASE/src/ [cdrom.com]. However, just remember that FreeBSD is more than just a kernel, it is an Operating System.
  • 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
  • by account_deleted ( 4530225 ) on Tuesday July 06, 1999 @02:09AM (#1817470)
    Comment removed based on user account deletion
  • >Using a bourne shell to conduct tests is not something I would view as particularly useful;

    Have you even looked at the script? It's just a small wrapper than launches ab, which is a standard benchmarking tool bundle with Apache.
  • Netcraft says: perl.pattern.net is running Apache/1.3.6 (Unix) mod_perl/1.19 on Linux
  • 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).

    Hmm, I *was* logged in, wasn't I?



  • Impressive indeed..

    Less than 15 minutes from post to death. Must be a new record or something...

    I've used all kinds of web servers, from IIS on winNT and WebSTAR on MacOS to Apache on Linux, FreeBSD and MacOSX. I must say that my most liked experiences came from the unicies, although WebSTAR comes close.

    Hopefully the site is back online later today, I'd like to see some of the numbers...

    my $0.02 CAD

  • It's Linux 2.2.x
  • 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.
  • FreeBSD 4.0 uses a single kernel lock currently. That may change before release depending on whether someone competent does the work.
  • I have read here and elsewhere that progs run faster under emulation in bsd than either native bsd apps in bsd, or native linux app in linux.

    There is some technical reason that I have forgotten, but it is apparently true.

    -- Reverend Vryl

  • As I pointed out for the Mindcraft stuff, these are some common problems in modern Web benchmarks:

    1. in the "real world" a mix of pages are being requested at once, so flat files and cgi and mod_perl should be tested all at once.
    2. the clients (not via localhost, of course) should simulate a variety of connect speeds so that the server has to deal with pumping lots of data fast as well as keeping lots of connections up while slow clients download.
    3. clients should also simulate partial downloads, this can change the dynamic for cgi a great deal.


    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/)
    Host (206.107.112.9) appears to be up ... good.
    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


  • by albator ( 40740 ) on Tuesday July 06, 1999 @02:47AM (#1817481)
    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 [swarthmore.edu] 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 [swarthmore.edu].
  • by Pingo ( 41908 )
    Could it be a WinLose server?
  • This looks like a pretty even race.

    No winner, no loser in this configuration

    I think my old tagline summarises it pretty well.

    //Gunnar

  • 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

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

    Mong.

    * Paul Madley ...Student, Artist, Techie - Geek *
  • By the look of it, it was Win3.1 :)

    Mong.

    * Paul Madley ...Student, Artist, Techie - Geek *
  • Steven,

    No offense, but why was your posting instantly uprated to a "2" score?

    Hmm, somebody likes you ;)

    Mong.

    * Paul Madley ...Student, Artist, Techie - Geek *
  • I bow to your superior wisdom oh wise one!

    On this basis though, somebody could write low-quality messages frequently, and then get a higher score automatically.

    Benefits outweigh the disadvantages though, I guess.

    Mong.

    * Paul Madley ...Student, Artist, Techie - Geek *
  • Whomever says they got it working is a liar.. Vmware forces the use of kernel modules which FreeBSD can't emulate.

    That's why I'm still using linux on my workstation computer :). (Well that and creative labs only released binary sblive drivers)
  • It also seems to me that the benchmarking routines should be doing something a little more complex than printing 'hello world'. In reality, the benchmark should be reading/writing to files, and pulling data from files to print to the screen. This would be more of a test than a stupid 'hello world'.

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Working...