how to make the FreeBSD 6.0 run faster

[ray at redshift.com]

At 07:01 AM 10/28/2005 -0500, Sergey Babkin wrote:
| >From: Robert Watson <rwatson at FreeBSD.org>
| >On Thu, 27 Oct 2005, Vaibhave Agarwal wrote:
| >
| >> How do u disable malloc debugging flags in the userland? I read 
| >> somewhere that " ln -s aj /etc/malloc.conf" disables malloc debugging. 
| >> How does it work?
| >>
| >> And how to disable verbose features in the kernel?
| >>
| >> Apart from this, are there other ways to make the kernel run faster??
| >
| >Other than that, you'll need to tell us what you're doing.
| 
| And the most important part: try to optimize your application 
| first. I've seen a surprizing number of people who feel
| that they need to do something with the kernel while what
| is really suboptimal (or downright broken) is their application.
| When writing programs people make many assumptions about
| what is fast and often these assumptions are wrong, plus
| there are bugs where the code generally works but does it slowly.
| This is especially true for applications written in C++
| and other OO languages, and for threaded applications. 
| If you want to have a cost-efficient solution, the applications 
| really need to be profiled and measured, and all the performance 
| squeezed out of them before going into the kernel.
| 
| -SB
| 

I will second that.  In some recent benchmarks I did with our web application, I
discovered that I was able to get a nearly 200% boost in speed (i.e. things ran
twice as fast) by simply changing how I was handling variables in PHP.

The golden rule of performance tweaking is *assume nothing, test everything*.  I
have read papers on PHP for example that swear up and down that removing
comments will not improve speed and that it's just a myth.  BS, removing
comments does improve speed because the interpreter has less to sift through.

Usually performance tuning is the combination of many small improvements, not
any one major short fall.  Without knowing your exact application, I can't say
specifically, but in most all of my cases, the Kernel itself (even when fully
optimized) only added about 20 or 30% to any given situation.  

In my experience, what makes a server scream is the combination of many small
performance increases including everything from faster hard drive, more
streamlined kernel, streamlined apps, better compilation, better coding on your
application, better threading, etc, etc.  Eventually you'll reach a point where
the time needed to produce further gains becomes a diminishing returns situation
and/or stability would have to be sacrificed.  At that point, generally it's
better, cheaper and faster to just add additional hardware (assuming you are
working in a cluster).

But to echo what Sergey says, you'd be surprised how often poor coding is the
root of the problem, not the kernel.

Ray