From owner-freebsd-performance@FreeBSD.ORG Sat May 20 17:21:46 2006 Return-Path: X-Original-To: performance@freebsd.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9898716A48C for ; Sat, 20 May 2006 17:21:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 153B743D62 for ; Sat, 20 May 2006 17:21:44 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A8FF346C2C; Sat, 20 May 2006 13:21:43 -0400 (EDT) Date: Sat, 20 May 2006 18:21:43 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: <446D9DEE.4050300@fer.hr> Message-ID: <20060520181834.L8068@fledge.watson.org> References: <446CCE1C.1050200@fer.hr> <446CD873.9080903@stevehodgson.co.uk> <446CE6CE.50009@fer.hr> <446D8994.3070709@thebeastie.org> <446D9DEE.4050300@fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: performance@freebsd.org, Steve Hodgson , Michael Vince Subject: Re: (Another) simple benchmark X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2006 17:21:47 -0000 On Fri, 19 May 2006, Ivan Voras wrote: >> If I was working on a project such as Apache I know I wouldn't be >> concentrating of performance with prefork in this day when threaded modes >> are where Apache has been aiming for modern high performance web serving >> for a fair while now. > > Did you miss discussions about how FreeBSD's threading sucks? Ok, "sucks" is > maybe a too strong strong word, but if you look for recent discussions about > MySQL, you'll see that the difference between Linux and FreeBSD performance > is huge. BTW, there seems to be a fundamental misunderstanding of the benefits of threading in the application developer community. Threading is actually worse for performance for a number of application cases. These tend to be cases where the kernel data structures shared across threads are accessed intensely across a pool of threads that actually could operate with greater independence. For example, pre-forked web servers vs pre-threaded web servers. If relatively little computation takes place, and it's all a series of accept()/send()/sendfile()/close() operations in many threads, you pound the locks protecting file descriptor state in the process. If it were different processes, the file descriptor state wouldn't be shared, so performance would be greater, even though the context switch cost is greater. I've observed this in micro-benchmarks on a number of OS platforms. Threading is good for application performance where a high level of sharing is absolutely necessary -- worker threads working on shared data in a shared address space, passing file descriptors between them, lots of synchronization, etc. In many other cases, it's not only not a benefit, but a significant overhead. Robert N M Watson