From owner-freebsd-hackers Fri Apr 20 9:47:59 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 89A4837B423 for ; Fri, 20 Apr 2001 09:47:55 -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 JAA07871; Fri, 20 Apr 2001 09:47:49 -0700 (PDT) (envelope-from jef@bomb.acme.com) Message-Id: <200104201647.JAA07871@bomb.acme.com> To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. In-reply-to: Your message of Fri, 20 Apr 2001 09:33:50 PDT. From: Jef Poskanzer Date: Fri, 20 Apr 2001 09:47:49 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> 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. > >Yes and no, the sendfile can block until all the file is sent, >however if the socket is in non-block mode it will abort when the >socket buffer fills. Basically, just how write can return a short >count, so will sendfile. Yeah, you're right, I looked at that man page just after sending my earlier message. That sounds pretty useful. >> 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. > >Yes, interesting, how did you manage the locking on this map? Let's see... Ok, first I was using shmget()/shmat(), not an anonymous mmap(). Locking, hmm. Looks like I didn't do any! Whoever had the accept token also was the one responsible for passing it to the next worker. And in case a worker died unexpectedly, the parent process stuck around and monitored things, restarting dead workers or adding new ones if the load gets high. >> - 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 > >Actually this is not a problem on FreeBSD, FreeBSD uses "wakeup_one()" >for accept() so "we" don't have this problem. Neato. >There was something else I mentioned in a previous mail that I >neglected to cc you on. While tracing thttp I noticed that it does >a lot of stat(2) calls, if you implemented a binary tree that kept >a cache of recently stat()'d filename (it would only last about 1 >or 2 seconds in the cache) then you'd be able to save a signigigant >amount of time doing that syscall. Yeah, I've thought of that too. A stat cache. It would probably help a little. --- 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