> under a simulated load of 50 users during 5 minutes, the results were:
> WebServer/OS Request per second
> =============== =====================
> apache 1.3.6/Linux 398 request/sec
> IIS 4.0/ NT server 4 200 requests/sec
> apache 1.3.6/FreeBSD-3.2 18 req/sec
A previous response has noted that Linux optimizes IDE hard drive
performance by default, but FreeBSD does not. I'd like to expand on this.
In general, Linux makes certain optimistic assumptions about
hardware. FreeBSD tends to be more conservative in these regards, and is
Now, if your hardware meets the optimistic assumptions that Linux
makes, and nothing ever goes wrong, then Linux will probably perform
better than FreeBSD, unless you take care to configure your system so that
your installation of FreeBSD makes the same optimistic assumptions.
A better way to solve this problem is to find out which assumptions
you can relatively safely make for your hardware, and implement those
assumptions both under Linux and FreeBSD. Then compare the performance.
If you do this, I believe you will find that FreeBSD will perform
roughly equal to Linux, if not better in virtually all cases. In
particular, the Linux network code right now is not very good, and the
FreeBSD stack is much better. Linux himself recognizes this problem, and
it's one of the many, many things that are planned to be fixed for kernel
version 2.4, but Ghu-only-knows how many years away that might be.
Now, let's take this a step further. By default, Linux mounts
filesystems asynchronously. This increases the chances that your system
will not be able to repair the filesystem, should there ever be an
unexpected system crash. The busier your filesystem that's mounted async,
the greater the chance that it will be permanently screwed up in a crash
and that you'll have to wipe it clean and restore your latest version from
FreeBSD pessimistically assumes that you're willing to put up with
lower system performance in return for greater system reliability in the
face of a crash.
However, if you look at the LINT kernel, you'll note at the bottom is
a feature called "SOFTUPDATES". If you follow the instructions and enable
this feature on your busy filesystems, they should perform every bit as
fast as Linux does when mounting the filesystem async, but there should be
no more danger in them being permanently screwed up by a crash than if you
mounted them sync. This way, you really can have your cake and eat it
Of course, you don't want to run something unless you actually need
it, so while you'll want to build your kernel and enable softupdates,
you'll actually only want to turn on softupdates for those busy
filesystems where it will be of use, primarily ones where lots of
temporary files are being created and then deleted very soon thereafter.
So, softupdates would be good for a separate /var/tmp filesystem (you
might want to run /tmp as an mfs filesystem, in the same way that Solaris
allows), or for a sendmail /var/spool/mqueue, or for an INN
/var/spool/news. Using softupdates may or may not buy you anything on a
busy /usr/local/share/apache/htdocs filesystem, depending on the nature of
the web pages you're serving up and the other filesystem activity.
I'm not sure how long you've been in the computer industry, but you
may remember many years ago that a company called Borland had a compiler
called Turbo Pascal. The reason it sold so many copies was because it
appeared to be blindingly fast, and was relatively inexpensive. However,
it was "blindingly fast" because they turned off all checking by default.
If you took that same kind of behaviour and implemented it with the
other major Pascal compilers at the time, they would run just as fast (or
faster) than Turbo Pascal. The difference was that they had virtually all
checking turned on by default, so that if there was a problem with your
program, you'd find out about it sooner rather than later.
These days, Linux is kind of like Turbo Pascal. They run fast, but
they run with most safety checks turned off by default. If you never fall
off the high wire, then you didn't need any of those safety checks to
begin with. However, if you do fall, then not having them means it's
*really* going to hurt when you actually fall and go *SPLAT*.
FreeBSD turns on all of the safety devices by default, and although
you'll run slower out-of-the-box, you'll really appreciate having all
those safety devices if/when you ever do fall off the high wire.
Of course, people really only care about this problem once they've
actually fallen. And if you've grown up in a more conservative OS
environment (e.g., FreeBSD), then you may not really appreciate all those
safety checks until such time as you're operating somewhere without them,
and you have a *really* rude surprise when there's nothing there to catch