Messages in this thread | | | Subject | Why khttpd is a bad idea (was a pointless argument about devfs) | Date | Fri, 18 Jun 1999 11:48:00 +0100 (BST) | From | Alan Cox <> |
| |
> I find khttpd is a reasonable idea. I dont know what youre talking about > with "lower performance than a user space httpd", > http://www.fenrus.demon.nl/ seems to indicate otherwise -- what > performance measurements were you looking at? B)
phhttpd.
> Now if you plug khttpd in front of apache the advantages become obvious. > Apache isnt exactly a speed demon -- but with khttpd it could be.
Apache 2.0 should be.
BTW: the big issue with khttpd is a lack of genericness. Its a single problem single solution piece of code. There are lots and lots of equivalent problems and they all boil own to the same thing.
Forget khttpd. Throw most of it away. Now implement asynchronous sendfile. This is quite doable.
There are two ways to tackle it.
#1 You allow the issuing of page cache read requests from bh handlers. Elegant, fast and truely horrible to do right
or
#2 You have a single kernel thread that takes a queue of page requests and basically grabs stuff whenever it is wanted (kslurpd)
With these pages being drawn into memory you can move the socket sendfile state machine loop into the sock->data_ready() callback so that the application becomes
while(1) { wait accept|sigio+siginfo
if(accept) { accept set O_NDELAY|FASYNC async_sendfile(....) } if(sigio) { close(fd); } }
An async sendfile solves the thread scaling problem , solves the 'do I feed this request to the kernel' problem, solves the HTTP 1.1 persistence problem, and works for ftp, finger, gopher... etc
Alan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |