From owner-freebsd-performance@FreeBSD.ORG Mon Mar 14 23:15:16 2005 Return-Path: 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 F23B916A4CE for ; Mon, 14 Mar 2005 23:15:15 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E22A43D2F for ; Mon, 14 Mar 2005 23:15:13 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id 12F2AC9AB7; Mon, 14 Mar 2005 15:15:13 -0800 (PST) Received: from mail.trippynames.com ([127.0.0.1]) by localhost (rand.nxad.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20273-06; Mon, 14 Mar 2005 15:15:10 -0800 (PST) Received: from [192.168.102.100] (dsl231-047-005.sea1.dsl.speakeasy.net [216.231.47.5]) by mail.trippynames.com (Postfix) with ESMTP id E08C9C9AB6; Mon, 14 Mar 2005 15:15:09 -0800 (PST) In-Reply-To: <3.0.1.32.20050310193015.00a7e908@pop.redshift.com> References: <3.0.1.32.20050310180051.00a7e908@pop.redshift.com> <3.0.1.32.20050310180051.00a7e908@pop.redshift.com> <3.0.1.32.20050310193015.00a7e908@pop.redshift.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <562e6c1c0720b8cc79f03b71942b08c4@chittenden.org> Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Mon, 14 Mar 2005 15:15:07 -0800 To: ray@redshift.com X-Mailer: Apple Mail (2.619.2) cc: freebsd-performance@freebsd.org Subject: Re: performance modifications X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2005 23:15:16 -0000 > | There are better web servers than Apache for demanding loads; > | ones that used a non-forking, event-driven I/O model. > | Aolserver and thttpd come to mind. > > I tried thttpd a number of years ago, but due to its limited cgi > support (at > least at the time) I didn't do too much with it. It did seem fast, > however. thttpd is a favorite of mine because of the time I've spent in its guts rewriting it for clients, but embedding PHP into it will never work well because of the way the code is written and organization. Recently I've been playing around with lighttpd and am very impressed. It's BSD licensed (3 clause) and has quickly become my new webserver of choice (*mutters something about Rails*). It even supports keep-alives well, which is something that thttpd doesn't do too well. Here are some benchmarks put out by a commercial webserver company, Lite Speed. http://www.litespeedtech.com/benchmark.html The lightspeed webserver guys are keen to point out that their webserver is the fastest on the block, but I'm skeptical of their results given the utility they're using for testing. I'm in the midst of writing a kqueue(2)/pthreads(3) backed web-benchmark program that will hopefully show that the gap between lighttpd and lite speed is smaller than the above benchmarks point out (if there's any difference at all). Any testing utility that's select(2) backed is going to suck up more resources than the server.... but I digress. If you're doing PHP, lighttpd should work very well for you and certainly be orders of magnitude better than Apache. http://www.lighttpd.net/ Having skimmed through the lighttpd code, the areas that it could improve are: *) pre-forking a pool of backends for CGI requests (lighttpd gets crushed by litespeed here) *) mmap(2)'ing buffers to reduce the overhead of writev(2)'ing data out over the network (ie: reduce copying of userland data to the kernel) *) use Boehm GC or make use of a memory pools that stay around longer than a connection. Right now every connection gets its own memory pool which is a problem in non-keep-alive connections. At the beginning and end of a connection, a pool gets allocated and free'ed. Free'ed memory from other connections is only reused by malloc(3), not by the OS. *) A better method of appending data to buffers (ie, use the same idea from Boehm's Cord library to reduce the costs of appending strings of data). Right now it uses memcpy(3) and it should just add a pointer to an array and realloc(3) the pointer array when the pointer array gets full instead of copy'ing data around. *) Divvy out requests to a pool of worker threads much the same way that Cherokee does (a thttpd based webserver that's been adapted to use pthreads... ie, thttpd on steroids) http://www.alobbs.com/modules.php? op=modload&name=News&file=article&sid=104 The improvement should come with threaded processing and dispatching of requests. Right now that's serialized and is the difference between litespeed pro and litespeed. That's also one of the ways that Cherokee makes its speed improvements over other webservers. -sc -- Sean Chittenden