From owner-freebsd-performance@FreeBSD.ORG Fri May 19 09:02:19 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 7D50016A41F for ; Fri, 19 May 2006 09:02:19 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22FB943D48 for ; Fri, 19 May 2006 09:02:16 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 889FA4D00C; Fri, 19 May 2006 09:04:22 +0000 (GMT) Received: from [192.168.46.102] (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 26C944C822; Fri, 19 May 2006 09:04:20 +0000 (GMT) Message-ID: <446D8994.3070709@thebeastie.org> Date: Fri, 19 May 2006 19:02:12 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20060404 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan Voras References: <446CCE1C.1050200@fer.hr> <446CD873.9080903@stevehodgson.co.uk> <446CE6CE.50009@fer.hr> In-Reply-To: <446CE6CE.50009@fer.hr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: performance@freebsd.org, Steve Hodgson 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: Fri, 19 May 2006 09:02:19 -0000 Interesting that the linux you are claiming to use would use prefork Apache as default, while this is the default on FreeBSD I would think the threaded worker would be used on a lot of linux dists, since they don't have the option to easily rebuild it. Even if it is using prefork, the Linux Apache conf prefork settings already are set higher, the start up server is 8 and has a higher max spare server setting of 20 (double the setting of default FreeBSD setting), I have found that ab is a kind of weird program and initial settings of the Apache server (its ability to initially respond) do adversely affect its ability to do the ab benchmark for some reason. Considering you are trying to initiate 100 connections at the same time with a prefork server that even one the better configured Linux side (with 8 initial servers which would quickly jump to 13) its not a very valid benchmark setup, especially with the unforgiving ab benchmark tool Something else you should look at when using Apache on FreeBSD is the Apache accept kernel module to save context switches which is aimed at increasing performance. man accf_http Sometimes I look at the ab program as something that better shows off the abilities of the Zeus server considering that the ab benchmark tool doesn't have some sane benchmark options such as constant connection rate modes unlike programs like 'httperf' do (which is in the ports tree) Such simple settings such as prefork might work fine for people running a simple CGI site or a PHP site (if there not going to load zend performance modules or use the encoder), if you have done benchmarks on PHP its surprisingly slow technology, on top of the fact that PHP folk recommend nothing other then prefork mode with PHP. 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. Mike Ivan Voras wrote: > Sorry, I forgot about performance@ mailing list, moving the discussion > there - please use performance at freebsd.org or equivalent address > when replying (and drop current@). > > Steve Hodgson wrote: > >> Ivan Voras wrote: >> >>> Today I had the opportunity to experiment for a short time with a >>> 4-CPU Xeon machine with hyperthreading (-> 8 logical CPU-s) and 3GB >>> RAM. In absence of anything smarter to do, I installed WBEL 3 Linux >>> (non-RedHat version of RedHat Enterprise Linux) which was accidentally >>> on the table and after toying around I've run a simple benchmark - ab >>> (apachebench, included by default with apache server) over localhost >>> to a local apache2 server, on a static home-page file. The command >>> line was "ab -n 100000 -c 100 http://localhost/". Since I still had >>> time with the machine, I then downloaded and installed FreeBSD 6.1 to >>> try to beat the score. Unfortunately, not only I couldn't beat the >>> score, but the results were *extremely* bad. Since I'm still not sure >>> it isn't my fault, I won't post the actual results, but I wonder... >>> >>> Apache is a well known server-grade product, which doesn't use >>> threading (it was preforked in both systems), doesn't call >>> gettimeofday() constantly, uses sendfile(), and in short, is very >>> different from MySQL. It shouldn't behave this badly on FreeBSD. >>> >>> Some observations from the benchmark runs: >>> - Linux was maxed out with ~50% total idle time, each logical >>> processor (hyperthreading was enabled) had ~25% user + ~25% sys time. >>> It still delivered order-of-magnitude better results. WBEL3 uses Linux >>> 2.4.x kernel (i.e. old kernel) >>> - FreeBSD CPU time was 100% spent, with 90%-95% spent in sys time >>> - On FreeBSD, enabling hyperthreading got me a slowdown of *4x* over >>> the initial (bad) results (some slowdown is not surprising, 4x >>> slowdown is). >>> - Linux "load average" never went above 8, FreBSD's went > 60; this >>> could be just a difference in accounting, or it could not - I don't >>> know. >>> >>> What is needed to reproduce this simple benchmark: >>> - SMP machine, the more CPUs the better >>> - installed software: only apache20. The "ab" benchmark is included in >>> it. Leave apache's default configuration as-is (i.e. preforked, max >>> 150 parallel clients allowed) >>> - A simple static HTML page (Apache's default "welcome, but this site >>> is not configured" should be ok). >>> - my invocation of "ab" was with "-n 100000 -c 100" ; the (n)umber of >>> requests could be modified to fit local CPU speed, but (c)oncurrency >>> shouldn't (100 parallel requests is not uncommon). >>> >> >> Apache may not use gettimeofday, but ab certainly does. here is a truss >> output of ab:... > > > I don't think this would result in 90% time being spent in sys with > large load averages. > >> A fairer test would be to use ab on a second box and keep ab on the same >> OS - you're changing two things at once here. You're also at the mercy >> of how the scheduler places the processes across the different CPU's >> (since there is one ab process and multiple httpd processes). Why was >> Linux stuck at 50% utilization per CPU (surely it should reach 100% with >> no disk or network constraints)? Perhaps it is sleeping whilst FreeBSD >> spins? > > >> If you are interested in performance try Lighttpd - that is what people >> use if they want high transaction rates (x10 higher in tests I've done >> on Linux) - and it is a single process so scheduling isn't so >> significant. > > > Using lighttpd or ab on other host is not really applicable - I wasn't > trying to configure the box for production, only ran the benchmarks > out of curiosity. Apache *should* work ok out of the box on FreeBSD :) > (btw. apache was installed from binary package) > > Here are the apache config files: > http://ivoras.sharanet.org/stuff/httpd.conf.tbz > > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org"