From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 13:35:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8540416A41F; Fri, 28 Oct 2005 13:35:19 +0000 (GMT) (envelope-from ray@redshift.com) Received: from mail.quickmeet.com (quickmeet.com [216.228.17.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id A932E43D45; Fri, 28 Oct 2005 13:35:17 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (workstation [192.168.20.250]) by mail.quickmeet.com (Postfix) with SMTP id 7294617032; Fri, 28 Oct 2005 06:07:51 -0700 (PDT) Message-Id: <3.0.1.32.20051028063522.00a75268@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Fri, 28 Oct 2005 06:35:22 -0700 To: babkin@users.sf.net, Vaibhave Agarwal From: ray@redshift.com In-Reply-To: <20858923.1130500901324.JavaMail.root@vms062.mailsrvcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd , freebsd Subject: Re: Re: how to make the FreeBSD 6.0 run faster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 13:35:19 -0000 At 07:01 AM 10/28/2005 -0500, Sergey Babkin wrote: | >From: Robert Watson | >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