I'm using Apache + mod_lisp for an intranet application for a huge corp.
As it's an important application they want a 100% uptime. This does not mean
a 100% uptime for a particular Lisp process on a given computer. What they
want is that there is always a Lisp process to reply to the HTTP requests.
The target computers are preferably FreeBSD or Linux boxes but they are
willing to buy anything else if that fits better (if there is a Lisp
compiler for it of course!)
Any ideas ?
BTW I would be interested too, if somebody has pointers on studies that says
that FreeBSD is more stable for this kind of applications that Linux. Or
what Linux distribution is more stable etc. No flame war please I don't want
to know what OS is best, I just want to know what OS+Apache+mod_lisp+Lisp
combination is the more reliable.
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> I'm using Apache + mod_lisp for an intranet application for a huge corp.
> As it's an important application they want a 100% uptime. This does not mean
> a 100% uptime for a particular Lisp process on a given computer. What they
> want is that there is always a Lisp process to reply to the HTTP requests.
> The target computers are preferably FreeBSD or Linux boxes but they are
> willing to buy anything else if that fits better (if there is a Lisp
> compiler for it of course!)
>
> Any ideas ?
>
> BTW I would be interested too, if somebody has pointers on studies that says
> that FreeBSD is more stable for this kind of applications that Linux. Or
> what Linux distribution is more stable etc. No flame war please I don't want
> to know what OS is best, I just want to know what OS+Apache+mod_lisp+Lisp
> combination is the more reliable.
No studies, but I have anecdotal evidence :)
I can't speak for the Lisp part, but I can say that FreeBSD 3.3
+ Apache 1.2 + g++ 2.95 is stable enough to saturate the I/O on a good
machine. Unfortunately, I've not had the opportunity to try massively
high loads with Lisp. The most important part of this equation is
that the kernel doesn't panic on extremely high loads; that Apache 1.2
doesn't is good, but neither does 1.4, AFAIK, but it can induce kernel
panic :( [FreeBSD + threads + pathologically high loads sometimes=> panic]
I've heard equally good things about Debian Potato + Apache 1.2, but
haven't experienced it myself (too bad, I like glibc a lot more than
the FreeBSD libc, not that it matters for your purposes). Both
FreeBSD3.3 and Debian Potato are quite old, but that's good, because
they both maintain them, and continue to backport fixes. I've also
heard very good things about the stability of Solaris under very heavy
loads, but *only* on Sun hardware, which is expensive, even compared
to comparable-quality Intel stuff. It does have the advantage of
being high quality, though, which means that if you go the Intel
route, you need to be *really* careful when selecting the hardware --
never underestimate the ability of lousy hardware to bring everything
down under high loads.
As for the Lisp system, I'd reccomend trying it. Really abuse the
system, set up a distributed system to bring its load up as high as
you can, preferably to the point where the network card can't go any
higher, or the software can't, or the kernel panics. One thing to
watch out for under FreeBSD is that (at least in 3.3), mmap() can
create problems under high loads. So you'll want to find out how your
lisp system allocates its memory. Also, make sure your signal
handlers don't allocate memory or open any files, at least if they're
handing off critical data to other servers (as the system's coming
down), or you may get an unpleasant surprise.
"Thomas F. Burdick" <···@apocalypse.OCF.Berkeley.EDU> wrote
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > I'm using Apache + mod_lisp for an intranet application for a huge corp.
> > As it's an important application they want a 100% uptime. This does not
mean
> > a 100% uptime for a particular Lisp process on a given computer. What
they
> > want is that there is always a Lisp process to reply to the HTTP
requests.
> > The target computers are preferably FreeBSD or Linux boxes but they are
> > willing to buy anything else if that fits better (if there is a Lisp
> > compiler for it of course!)
> >
> > Any ideas ?
> >
> > BTW I would be interested too, if somebody has pointers on studies that
says
> > that FreeBSD is more stable for this kind of applications that Linux. Or
> > what Linux distribution is more stable etc. No flame war please I don't
want
> > to know what OS is best, I just want to know what
OS+Apache+mod_lisp+Lisp
> > combination is the more reliable.
>
> No studies, but I have anecdotal evidence :)
Great! I like "real world" stories...
> I can't speak for the Lisp part, but I can say that FreeBSD 3.3
> + Apache 1.2 + g++ 2.95 is stable enough to saturate the I/O on a good
> machine. Unfortunately, I've not had the opportunity to try massively
> high loads with Lisp. The most important part of this equation is
> that the kernel doesn't panic on extremely high loads; that Apache 1.2
> doesn't is good, but neither does 1.4, AFAIK, but it can induce kernel
> panic :( [FreeBSD + threads + pathologically high loads sometimes=>
panic]
Yuck! Fortunately the load is not supposed to be pathologically high.
The max load will be like 200 or 300 small HTTP requests per second.
BTW what do you call pathologically high loads ?
> I've heard equally good things about Debian Potato + Apache 1.2, but
> haven't experienced it myself (too bad, I like glibc a lot more than
> the FreeBSD libc, not that it matters for your purposes). Both
> FreeBSD3.3 and Debian Potato are quite old, but that's good, because
> they both maintain them, and continue to backport fixes. I've also
> heard very good things about the stability of Solaris under very heavy
> loads, but *only* on Sun hardware, which is expensive, even compared
> to comparable-quality Intel stuff. It does have the advantage of
> being high quality, though, which means that if you go the Intel
> route, you need to be *really* careful when selecting the hardware --
> never underestimate the ability of lousy hardware to bring everything
> down under high loads.
Sun hardware is an option indeed but I was asked to look at FreeBSD/Linux
alternatives as well.
> As for the Lisp system, I'd reccomend trying it. Really abuse the
> system, set up a distributed system to bring its load up as high as
> you can, preferably to the point where the network card can't go any
> higher, or the software can't, or the kernel panics. One thing to
> watch out for under FreeBSD is that (at least in 3.3), mmap() can
> create problems under high loads. So you'll want to find out how your
> lisp system allocates its memory. Also, make sure your signal
> handlers don't allocate memory or open any files, at least if they're
> handing off critical data to other servers (as the system's coming
> down), or you may get an unpleasant surprise.
I use LWL under FreeBSD 4.3 (4.4 soon)
FreeBSD 3.3 is really an old one and I think LWL won't work on it.
Thanks,
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Thomas F. Burdick" <···@apocalypse.OCF.Berkeley.EDU> wrote
>
> > No studies, but I have anecdotal evidence :)
>
> Great! I like "real world" stories...
>
> > I can't speak for the Lisp part, but I can say that FreeBSD 3.3
> > + Apache 1.2 + g++ 2.95 is stable enough to saturate the I/O on a good
> > machine. Unfortunately, I've not had the opportunity to try massively
> > high loads with Lisp. The most important part of this equation is
> > that the kernel doesn't panic on extremely high loads; that Apache 1.2
> > doesn't is good, but neither does 1.4, AFAIK, but it can induce kernel
> > panic :( [FreeBSD + threads + pathologically high loads sometimes=>
> panic]
>
> Yuck! Fortunately the load is not supposed to be pathologically high.
> The max load will be like 200 or 300 small HTTP requests per second.
> BTW what do you call pathologically high loads ?
The meaning of "pathological" depends on the hardware: I'd call
pathologically high >= 99% CPU, > 500 req/sec, sustained for more than
15 minutes. The req/sec would vary depending on the hardware, though.
I doubt an IBM 360 admin would consider that situation pathological.
I was using "pathological" to mean "whatever starts to cause kernel
problems", though, which is true by definition for a given system, but
admittedly not that useful :).
Also, since you seem to just want high availability (fault tolerance
for a system like this would certainly include HA, but not the other
way around), you might not be quite so scared of anything going wrong.
If you have an incomming stream of data that you can't slow down, that
you cannot lose a bit from, nor request that a bit be resubmitted,
then I think you're looking for a FT system in which a server that
discovers it's in trouble absolutely has to ensure that it hands off
its current state of computation before going down. If it can lose
that state, then it can just go down, and let the other servers deal
with its requests while it restarts. Not that kernel panics are ever
good, but they just suck, instead of being the end of the world, if
you can have the client resubmit the request.
> > I've heard equally good things about Debian Potato + Apache 1.2, but
> > haven't experienced it myself (too bad, I like glibc a lot more than
> > the FreeBSD libc, not that it matters for your purposes). Both
> > FreeBSD3.3 and Debian Potato are quite old, but that's good, because
> > they both maintain them, and continue to backport fixes. I've also
> > heard very good things about the stability of Solaris under very heavy
> > loads, but *only* on Sun hardware, which is expensive, even compared
> > to comparable-quality Intel stuff. It does have the advantage of
> > being high quality, though, which means that if you go the Intel
> > route, you need to be *really* careful when selecting the hardware --
> > never underestimate the ability of lousy hardware to bring everything
> > down under high loads.
>
> Sun hardware is an option indeed but I was asked to look at FreeBSD/Linux
> alternatives as well.
If I were you, I'd start looking for hardware first, because getting
Intel hardware comperable to Sun quality is pricey. You might be able
to get Sun to match the price, or near enough. They're certainly
famous for being open to haggling.
> > As for the Lisp system, I'd reccomend trying it. Really abuse the
> > system, set up a distributed system to bring its load up as high as
> > you can, preferably to the point where the network card can't go any
> > higher, or the software can't, or the kernel panics. One thing to
> > watch out for under FreeBSD is that (at least in 3.3), mmap() can
> > create problems under high loads. So you'll want to find out how your
^^^^^^^^^^---> "sustained high CPU loads"
> > lisp system allocates its memory. Also, make sure your signal
> > handlers don't allocate memory or open any files, at least if they're
> > handing off critical data to other servers (as the system's coming
> > down), or you may get an unpleasant surprise.
>
> I use LWL under FreeBSD 4.3 (4.4 soon)
> FreeBSD 3.3 is really an old one and I think LWL won't work on it.
Yeah, I'd imagine they don't. Not much recent software does. I'd try
asking around in FreeBSD circles about which 4.x would be best.
* I wrote:
> If I were you, I'd start looking for hardware first, because getting
> Intel hardware comperable to Sun quality is pricey. You might be able
> to get Sun to match the price, or near enough. They're certainly
> famous for being open to haggling.
I think when choosing HW for this kind of thing there are important
considerations. It has to be good enough hardware (which means ECC
and redundancy and so on). You have to have a cast iron support
contract: when a box goes wrong a year or two down the line you want
people there to fix it really fast, night or day, and you want them
actually to be able to fix it (which means replace like with like: you
*really* don't want someone `upgrading' the ethernet card to something
that your OS does not support). Finally you want to be very sure that
the HW and SW vendors will not fight each other: you definitely do not
want your HW vendor claiming that it's an OS bug and the OS vendor
claiming that its a HW problem, as you'll then spend weeks trying to
get one of them to admit responsibility. Finally finally, you want to
consider the viability of the company you are buying stuff from:
typical HA-type systems run for years, and you want to be very sure
that whoever you buy stuff from is still there when you need them.
In practice this points you very strongly in the direction of a small
number of vendors. I won't enumerate them here ...
As a side note, it's important to remember that almost any HW you buy
is likely to be a small part of the total costs: HW is really cheap
nowadays. You shouldn't get hung up because your chosen vendor is a
little more expensive than a vanilla PC from your local supermarket:
by the time you've worried about the price you've probably spent more
than the difference in time costs worrying.
--tim
* I wrote:
>* I wrote:
No, I didn't, ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) did
and my over-clever emacs hack thought it was me. Completely automated
misattribution of quotes, how cool is that?
--tim
"Tim Bradshaw" <···@cley.com> wrote
> I think when choosing HW for this kind of thing there are important
> considerations. It has to be good enough hardware (which means ECC
> and redundancy and so on). You have to have a cast iron support
> contract: when a box goes wrong a year or two down the line you want
> people there to fix it really fast, night or day, and you want them
> actually to be able to fix it (which means replace like with like: you
> *really* don't want someone `upgrading' the ethernet card to something
> that your OS does not support). Finally you want to be very sure that
> the HW and SW vendors will not fight each other: you definitely do not
> want your HW vendor claiming that it's an OS bug and the OS vendor
> claiming that its a HW problem, as you'll then spend weeks trying to
> get one of them to admit responsibility. Finally finally, you want to
> consider the viability of the company you are buying stuff from:
> typical HA-type systems run for years, and you want to be very sure
> that whoever you buy stuff from is still there when you need them.
Good points.
> In practice this points you very strongly in the direction of a small
> number of vendors. I won't enumerate them here ...
> As a side note, it's important to remember that almost any HW you buy
> is likely to be a small part of the total costs: HW is really cheap
> nowadays. You shouldn't get hung up because your chosen vendor is a
> little more expensive than a vanilla PC from your local supermarket:
> by the time you've worried about the price you've probably spent more
> than the difference in time costs worrying.
You are right, in this kind of applications, HW cost is not a pb.
Marc
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > I use LWL under FreeBSD 4.3 (4.4 soon)
> > FreeBSD 3.3 is really an old one and I think LWL won't work on it.
>
> Yeah, I'd imagine they don't. Not much recent software does. I'd try
> asking around in FreeBSD circles about which 4.x would be best.
FreeBSD 3.x is *old*, and will not be supported for much
longer (actually, 3.x is already unsupported for every value of x
which is not 5, I think :-).
FreeBSD 4.3 was a *really* slick release which should be a
no-risk option. FreeBSD 4.4 will be released in a few days; there have
been a few issues with the "Release Candidates", but it seems that 4.4
will also be a high-quality release.
--
Raymond Wiker
·············@fast.no
"Thomas F. Burdick" <···@apocalypse.OCF.Berkeley.EDU> wrote
> Also, since you seem to just want high availability (fault tolerance
> for a system like this would certainly include HA, but not the other
> way around), you might not be quite so scared of anything going wrong.
> If you have an incomming stream of data that you can't slow down, that
> you cannot lose a bit from, nor request that a bit be resubmitted,
> then I think you're looking for a FT system in which a server that
> discovers it's in trouble absolutely has to ensure that it hands off
> its current state of computation before going down. If it can lose
> that state, then it can just go down, and let the other servers deal
> with its requests while it restarts. Not that kernel panics are ever
> good, but they just suck, instead of being the end of the world, if
> you can have the client resubmit the request.
You are right what is needed is high availability not fault tolerance.
> > Sun hardware is an option indeed but I was asked to look at
FreeBSD/Linux
> > alternatives as well.
> If I were you, I'd start looking for hardware first, because getting
> Intel hardware comperable to Sun quality is pricey. You might be able
> to get Sun to match the price, or near enough. They're certainly
> famous for being open to haggling.
They already have rooms full of Suns so adding a few ones won't be a
problem.
I think I will develop under FreeBSD and then probably port to a Sun.
Marc
Hi Marc!
I think that there are many ways to handle your client's requirement.
First of all, I understand the problem you describe as one of High Availability
(HA) instead of one of Fault Tolerance (FT).
HA provides answers to problems of "if anything breaks the user must not
notice". FT, as I remember to have been taught and read about, is related to
"if a program or algorithm produces wrong results the overall application must
not be affected" or, also, "if a single component produces a different result
than at least two other components resolving the same problem then the
majority wins".
A 100% uptime - of what? Including planned downtime (which then will not
exist !)?
And related to which time-frame? One day? A week? A Year?
So, HA, to finally come to a possible answer to your client's requirement, may
be achieved by several means:
1. IT Architecture
This would concepts of redundancy on H/W level. Every single component on
network and machine level has to be deployed at least twice. Connection
schemes (down to the actual cabling level) should be done to reflect this
redundancy. If you need more info on this - well, I'm part of
HP Consulting ;-)
For a typical WWW application (as seen from the user) this would most likely
also involve load balancers and traffic directors. These components
distribute traffic such that, if a component fails or is not able to respond
in time (according to defined thresholds or other decision criteria) another
machine is selected. To support such a way of handling traffic (user requests)
the application has to be designed accordingly.
The session and state handling has be done in a persistent way (DB or somehow
else). The persistence data must reside on a medium concurrently accessible
by all servers. An incoming request may then be answered by any machine
regardless on which machine a previous request of the same user (the same
session) was answered.
If only 99,999% availability is required (related to real availability over an
unlimited time-frame) a HA server cluster solution will serve your needs.
A side aspect of HA is security. Security prevents "unwanted" usage and
therefore also increases application availability. But this is another story
to be told on another occasion.
2. Application Level (only)
This is a design issue. There are many aspects to be looked at. Experience
from many HA projects is that a real 100% availability is almost unachievable -
not because this is not feasible but because the client is not willing to pay
for. This is true for both IT and Application Level HA approaches.
On the application level HA normally involves some sort of persistence.
This is normally achieved in many companies by simple DBs - either RDBMS or
OODBMS. I'm sure you are aware of this :-)
But HA on application level includes all /applications/. This also includes
the OS and every single program running as a supporting environment for the
application. Each and every availability of these components comprise the
final availability equation. A 100% may only be achieved if everything "on
the left side" of the equation (being of the form x * y * z = a) has to be
100%!
In practice this is not achievable. Well, actually it is, but at very high
cost.
So, without _really_ knowing the client's requirements, I simply want to
draw up a normal approach:
Use a normal HA architecture as outlined above for the WWW environment up to
the Apache Web Server machines. Use persistence using a DB residing on a HA
server cluster. Use a separate firewall in front of the servers forming your
app env. Let Lisp run on a cluster (using the same machines as the DB cluster).
This will give you something like 99.995% overall availability - at least with
non-Intel platforms ;-))). Use SUN Solaris or HP-UX. Really. It is hard
experience speaking here. Because HA also (from the implementation view)
requires fast and reliable support from the vendor. Remember - 5 minutes
downtime in a year is too much. You better have support contracts protecting
you from any penalties here.
HTH.
Regards,
Frank
""Frank Goenninger"" <················@goenninger.com> wrote
> Hi Marc!
>
> I think that there are many ways to handle your client's requirement.
>
> First of all, I understand the problem you describe as one of High
Availability
> (HA) instead of one of Fault Tolerance (FT).
>
> HA provides answers to problems of "if anything breaks the user must not
> notice". FT, as I remember to have been taught and read about, is related
to
> "if a program or algorithm produces wrong results the overall application
must
> not be affected" or, also, "if a single component produces a different
result
> than at least two other components resolving the same problem then the
> majority wins".
>
> A 100% uptime - of what? Including planned downtime (which then will not
> exist !)?
> And related to which time-frame? One day? A week? A Year?
>
> So, HA, to finally come to a possible answer to your client's requirement,
may
> be achieved by several means:
>
> 1. IT Architecture
>
> This would concepts of redundancy on H/W level. Every single component on
> network and machine level has to be deployed at least twice. Connection
> schemes (down to the actual cabling level) should be done to reflect this
> redundancy. If you need more info on this - well, I'm part of
> HP Consulting ;-)
>
> For a typical WWW application (as seen from the user) this would most
likely
> also involve load balancers and traffic directors. These components
> distribute traffic such that, if a component fails or is not able to
respond
> in time (according to defined thresholds or other decision criteria)
another
> machine is selected. To support such a way of handling traffic (user
requests)
> the application has to be designed accordingly.
>
> The session and state handling has be done in a persistent way (DB or
somehow
> else). The persistence data must reside on a medium concurrently
accessible
> by all servers. An incoming request may then be answered by any machine
> regardless on which machine a previous request of the same user (the same
> session) was answered.
>
> If only 99,999% availability is required (related to real availability
over an
> unlimited time-frame) a HA server cluster solution will serve your needs.
>
> A side aspect of HA is security. Security prevents "unwanted" usage and
> therefore also increases application availability. But this is another
story
> to be told on another occasion.
>
> 2. Application Level (only)
>
> This is a design issue. There are many aspects to be looked at. Experience
> from many HA projects is that a real 100% availability is almost
unachievable -
> not because this is not feasible but because the client is not willing to
pay
> for. This is true for both IT and Application Level HA approaches.
>
> On the application level HA normally involves some sort of persistence.
> This is normally achieved in many companies by simple DBs - either RDBMS
or
> OODBMS. I'm sure you are aware of this :-)
>
> But HA on application level includes all /applications/. This also
includes
> the OS and every single program running as a supporting environment for
the
> application. Each and every availability of these components comprise the
> final availability equation. A 100% may only be achieved if everything "on
> the left side" of the equation (being of the form x * y * z = a) has to be
> 100%!
>
> In practice this is not achievable. Well, actually it is, but at very high
> cost.
>
> So, without _really_ knowing the client's requirements, I simply want to
> draw up a normal approach:
>
> Use a normal HA architecture as outlined above for the WWW environment up
to
> the Apache Web Server machines. Use persistence using a DB residing on a
HA
> server cluster. Use a separate firewall in front of the servers forming
your
> app env. Let Lisp run on a cluster (using the same machines as the DB
cluster).
>
> This will give you something like 99.995% overall availability - at least
with
> non-Intel platforms ;-))). Use SUN Solaris or HP-UX. Really. It is hard
> experience speaking here. Because HA also (from the implementation view)
> requires fast and reliable support from the vendor. Remember - 5 minutes
> downtime in a year is too much. You better have support contracts
protecting
> you from any penalties here.
Hi Frank,
Very interesting. You are right, they want High Availability not Fault
Tolerance.
They wanted to put a SUN server but asked me to look at alternatives as
well.
The normal HA architecture you describe seems OK for the need. I will just
have to look at what I can do for the session and state management.
A quick search for "High Availability" on google gives 311000 pages. So I
think I will learn a bit more on the subject...
Thanks,
Marc
Marc Battyani wrote:
> BTW I would be interested too, if somebody has pointers on studies that says
> that FreeBSD is more stable for this kind of applications that Linux.
I don't have any white papers, and am no expert, but...
I do know that our network designers preferred OpenBSD for ultimate
reliability as a server that happened to be sending requests off to
multiple lisp processes. This was for a huge (!) system being pounded on
by thousands of browsers. I was told BSD (esp FreeBSD) had a better
virtual memory subsystem, while OpenBSD had fewer security holes. We
ended up doing just fine with Linux, which had more market appeal, but
OpenBSD and secondly FreeBSD were the preference of the technical
people. This was nearly a year ago, so I don't know if these things have
changed.
Eric
BTW, how is mod_lisp doing? I was so happy to see it come into being.
Now I'm hoping to see lisp plug-ins for Netscape and IE. (Gawd I wish I
knew enough to tackle such a thing.)
"Eric Moss" <········@alltel.net> wrote
> I do know that our network designers preferred OpenBSD for ultimate
> reliability as a server that happened to be sending requests off to
> multiple lisp processes. This was for a huge (!) system being pounded on
> by thousands of browsers. I was told BSD (esp FreeBSD) had a better
> virtual memory subsystem, while OpenBSD had fewer security holes. We
> ended up doing just fine with Linux, which had more market appeal, but
> OpenBSD and secondly FreeBSD were the preference of the technical
> people. This was nearly a year ago, so I don't know if these things have
> changed.
It seems that a lot of people prefer one of the BSDs for servers but real
studies are hard to find.
> BTW, how is mod_lisp doing? I was so happy to see it come into being.
> Now I'm hoping to see lisp plug-ins for Netscape and IE. (Gawd I wish I
> knew enough to tackle such a thing.)
mod_lisp is doing fine, I personally already used it for several Intranet
application for big companies and I found that it was a good way to
introduce Lisp.
I could make an ISAPI extension for IIS if I had time, but it's rather
unlikely (well I could have to, if a client absolutely requires IIS).
Anyway, Apache works well under W2K and NT.
BTW I was asked for a SOAP application with mod_lisp. Does somebody know if
some Lisp stuff already exists for this ?
Marc
> "Eric Moss" <········@alltel.net> wrote
>
> > BTW, how is mod_lisp doing? I was so happy to see it come into being.
> > Now I'm hoping to see lisp plug-ins for Netscape and IE. (Gawd I wish I
> > knew enough to tackle such a thing.)
A couple years ago, I think, when my brother was trying to convince me
to learn JavaScript, I came across a lisp plug-in for Netscape. I
think it was CLISP-based. I remember this because my response was:
see, I don't need to learn JS, I can use Lisp, which I already know,
and just point browsers without the Lisp plug-in to download it. My
brother pointed out the difference between "could" and "should", which
might be why I can't find any pointers to the plug-in on google (which
I just tried).
Marc Battyani wrote:
>
> "Eric Moss" <········@alltel.net> wrote
>
> > I do know that our network designers preferred OpenBSD for ultimate
> > reliability as a server that happened to be sending requests off to
> > multiple lisp processes. This was for a huge (!) system being pounded on
> > by thousands of browsers. I was told BSD (esp FreeBSD) had a better
> > virtual memory subsystem, while OpenBSD had fewer security holes. We
> > ended up doing just fine with Linux, which had more market appeal, but
> > OpenBSD and secondly FreeBSD were the preference of the technical
> > people. This was nearly a year ago, so I don't know if these things have
> > changed.
>
> It seems that a lot of people prefer one of the BSDs for servers but real
> studies are hard to find.
Hmmm... I did a bit of googling, and found the following. Nothing
approaching scientific, but enough for a "true-believer" like me. ;)
Testimonials and reviews:
http://www.geocities.com/SiliconValley/Bay/6986/yahoobsd.htm
http://www.webtechniques.com/archives/2001/01/infrrevu/
http://www.zdnet.com/eweek/stories/general/0,11011,400844,00.html
http://www.cons.org/cracauer/freebsd.html (yea Martin!)
http://serverwatch.internet.com/reviews/platform-freebsd.html
http://www.timestretch.com/review/home/load/14/
Shootouts and tuning tips:
http://www.samag.com/documents/s=1147/sam0108q/0108q.htm
http://www.daemonnews.org/200108/benchmark.html
http://httpd.apache.org/docs/misc/perf-bsd44.html#detail
http://www.shub-internet.org/brad/FreeBSD/vinum.html
http://www.psc.edu/networking/perf_tune.html
http://www.nersc.gov/research/FTG/pcp/performance.html
http://www.volano.com/report/ (BSD awful for Java. Yea!)
Verification of performance (well, you have to run them...):
www.freebsd.org/ports/benchmarks.html
http://www.cs.duke.edu/~anderson/freebsd/cluster_mon/project.html
Enjoy, if you can. :)
Eric