From owner-freebsd-hackers Fri Apr 20 9:11:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bomb.acme.com (bomb.acme.COM [209.133.38.22]) by hub.freebsd.org (Postfix) with ESMTP id C1B0C37B43E for ; Fri, 20 Apr 2001 09:11:41 -0700 (PDT) (envelope-from jef@bomb.acme.com) Received: from bomb.acme.com (localhost [127.0.0.1]) by bomb.acme.com (8.9.3/8.9.3) with ESMTP id JAA95537; Fri, 20 Apr 2001 09:11:32 -0700 (PDT) (envelope-from jef@bomb.acme.com) Message-Id: <200104201611.JAA95537@bomb.acme.com> To: Alfred Perlstein Cc: sthaug@nethelp.no, hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. In-reply-to: Your message of Fri, 20 Apr 2001 05:23:37 PDT. From: Jef Poskanzer Date: Fri, 20 Apr 2001 09:11:32 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The accept-filters change is already on my short list to add. I'll probably use your version. sendfile() probably doesn't make sense in a non-blocking server - wouldn't it block until the entire file is sent? I do plan to use it in my other server mini_httpd. As for making thttpd use multiple processes (each doing non-blocking I/O), yes definitely. I did it in the commercial server I worked on for a while and it was a big win. There are two parts to this: - Collect global state into a single struct and share it among the processes via an anonymous mmap. This would include the throttling table. - A round-robin token-passing scheme to determine which process gets to do the accept(). Turns out it's very bad to just have all the processes do an accept(), since every time there's a new connection *all* the processes wake up. The context switches totally kill performance. But a properly tuned round-robin scheme works great. I'm not sure when I'll add this, but it's definitely in the works. --- Jef Jef Poskanzer jef@acme.com http://www.acme.com/jef/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message