Date: Fri, 20 Apr 2001 09:33:50 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Jef Poskanzer <jef@acme.com> Cc: hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <20010420093349.X1790@fw.wintelcom.net> In-Reply-To: <200104201611.JAA95537@bomb.acme.com>; from jef@acme.com on Fri, Apr 20, 2001 at 09:11:32AM -0700 References: <200104201611.JAA95537@bomb.acme.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Jef Poskanzer <jef@acme.com> [010420 09:11] wrote: > 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. 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. > 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? > - 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. Actually this is not a problem on FreeBSD, FreeBSD uses "wakeup_one()" for accept() so "we" don't have this problem. You may have problems on other OSs but apache includes a small library type thingy for serializing accepts for non optimal operating systems you should be able to lift a simple algorithm from it to serialize the accept()s on non optimal systems. You will have a problem if you make thttpd listen() on multiple sockets, becasue then you will need to run select() or poll() on the descriptors, a mear collision on the descriptor being selected on by processes wakes them all up (ie, the wakeup happens when the collision happens, not when the descriptors become ready). So adapting thttpd to listen on multiple sockets with multiple processes will be a bit difficult. > I'm not sure when I'll add this, but it's definitely in the works. Cool! any chance of putting it up as a sourceforge project with cvsup access so I can send proper diffs in the future? 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. -- -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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010420093349.X1790>