Date: Fri, 20 Apr 2001 09:47:49 -0700 From: Jef Poskanzer <jef@acme.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: hackers@FreeBSD.ORG Subject: Re: thttpd hack for sendfile and accept filters. Message-ID: <200104201647.JAA07871@bomb.acme.com> In-Reply-To: Your message of Fri, 20 Apr 2001 09:33:50 PDT.
index | next in thread | raw e-mail
>> 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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104201647.JAA07871>