Messages in this thread | | | Date | Tue, 23 Jun 1998 18:37:58 -0700 (PDT) | From | Dean Gaudet <> | Subject | Re: Thread implementations... |
| |
On Wed, 24 Jun 1998, Chris Wedgwood wrote:
> I was looking into this for sendfile(2), which can have similar constraints > and requirements.
It occured to me last night that sendfile() may not be the best thing... my latest scheme for speeding up apache involves what I'm calling "HTTP flows", and the short story is that the web server has a front-end and a back-end. The front-end is extremely light, dumb, and single threaded; the back-end is full featured, and looks almost the same as current apache. The front-end handles only well-formed HTTP requests and only requests that fit patterns that the back-end has fed it. In its simplest form it's a mapping from URL to mmap-region/FD (but it can handle far more than just these static-only servers). If sendfile() is blocking I can't use it for this.
I've got a prototype of this method already, and it outperforms threaded apache by a factor of 50%. It all makes sense when you sit back and realise the cache benefits from a single thread, not to mention the coding short-cuts I can take because I can punt any request that isn't well-formed to the slower, fully functional, backend. The backend is fully threaded (one thread per request) because it's far easier to let folks extend the server in a threaded programming model... the backend wouldn't have any problem with a blocking sendfile(). But the front-end is where sendfile() would be of the most use... right now it's a typical poll()/write() implementation.
Food for thought... glad to see someone is thinking about sendfile() :)
Dean
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |