From owner-freebsd-hackers Fri Apr 20 5:23:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 514B637B422 for ; Fri, 20 Apr 2001 05:23:41 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3KCNbN08738; Fri, 20 Apr 2001 05:23:37 -0700 (PDT) Date: Fri, 20 Apr 2001 05:23:37 -0700 From: Alfred Perlstein To: sthaug@nethelp.no Cc: hackers@FreeBSD.ORG, Jef Poskanzer Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <20010420052337.O1790@fw.wintelcom.net> References: <20010420044402.L1790@fw.wintelcom.net> <72342.987768654@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <72342.987768654@verdi.nethelp.no>; from sthaug@nethelp.no on Fri, Apr 20, 2001 at 02:10:54PM +0200 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG cc'd the author... * sthaug@nethelp.no [010420 05:11] wrote: > > Second, it looks like there's a few things in thttpd that could be > > optimized further. > ... > > .) pre-forking, this would help with stalling on disk IO. > > Since the author of thttpd makes a point of *not* using pre-forking (and > thttpd still being very fast), I'm not sure that pre-forking patches > would be accepted. > > See http://www.acme.com/software/thttpd/ I understand his reasoning, it's just that you need multiple contexts (processes) to be able to field disk IO without stalling when something isn't in memory. Basically, you want to keep the disks active, you can't do that very well with a single process unless you use aio. Matt Dillon said that he found that each child should handle about 20 connections using non-blocking IO. I imagine handling any more than that and a stall on disk would get pretty noticeable or just not be able to perform as well. The easiest way would be to have thttpd fork after listening a pre-determined amount of servers, then they'll all compete calling accept() to grab connections. What you'd loose is the ability to do the connection throttling unless you periodically communicated with a collector process that would gather stats and report when to implement throttling. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message