Re: In-Kernel HTTP Server (name preference)
On Wed, Feb 20, 2002 at 12:31:53AM +, Tony Finch wrote: Julian Elischer [EMAIL PROTECTED] wrote: I can suggest using a netgraph module for the work as it can be connected to a netgraph ksocket node to receive the requests (jdp made all the changes needed to allow this to be done). Another way would be to implement it as an accept filter which knows how to handle simple requests but drops anything more complicated down to a userland web server -- an unmodified Apache would be able to do the latter, since it already supports accept filters. Some way of configuring it is still needed, though... This may well be the right approach. But rather than handling simple requests, it should handle cacheable requests. But only if they're in it's cache - otherwise it passes them through to the userland web server, and cache the results. This is the approach that Sun took (except they used a STREAMS module, rather than an accept filter). -- Mike Bristow, embonpointful, but not managerial, damnit. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
On Tue, Feb 19, 2002 at 10:00:04AM -0800, Alfred Perlstein wrote: Disk IO can't be done in a non-blocking manner. If the kernel doesn't have the portion of the file you wish to read in the buffer cache then the process will block waiting. Isn't this exactly what the kqueue mechanism circumvents? I'm s confused - Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
Tony Finch wrote: [ ... Terry describes non-blocking I/O on page-not-present on SVR4, and how it behaves better than BSD ... ] How does it deal with the situation that the machine's working set has exceeded memory? If the web server is dealing with lots of concurrent connections it may have to block in poll() waiting for (say) a thousand pages to be brought in, then in the process of dealing with them after the poll() returns some of the pages may get re-used for something else making read() on a readable fd return EWOULDBLOCK again. It doesn't deal with this at all. SVR4 doesn't deal with overcommit of the working set at all well. I've pointed this out many times since 1992: the SVR4 linker maps all the involved object files into the linker, and then seeks all over heck (effectively) to do the relocation and the symbol table fixup. In this process, it thrashes out all the pages for the X server (among other things, but that's the most noticeable), and you lose control of the system until the link is done. FreeBSD has a slightly less difficult time with processes which are pigs in this way, mostly because it has a unified VM and buffer cache, so the contention between the VM and buffer cache allocations is no longer there. However, a correctly written program, designed to exercise the code path for the degenerate case will, well... exercise the code path for the degenerate case. SVR4 dealt with this issue by throwing the CPU at it: they have modular scheduler classes, and one of the ones they provide is called fixed, where a certain percentage of the CPU is dedicated to that task, whether it needs it or not. Thus the X server runs at a fixed class, and it thrashes the pages it needs back in in the time allotted to it, and the net effect is that when you move the mouse, the cursor wiggles, just like it's supposed to. This approach works for SVR4 _because_ the VM and buffer cache are not unified, and _cannot_ work for FreeBSD, because they are, since it can't attribute demand back to the demander. The correct fix for this problem is to set a high watermark for the amount of available system memory, and a high watermark per vnode. When you hit the high watermark for the system, then you are in a resource starvation situation; knowing this, then if you are asked to page a page in on a vnode, you check its page count, and, if it is over the second high watermark, then instead of taking an LRU page from the system, you steal the page from the page list on the vnode instead. The net effect of this approach is, in starvation situations (and _only_ in starvation situations!), you limit the per vnode working set size. Obviously, the VMS approach of limiting the per process working set size (via a working set quota) would be better, if you could enforce it, and if you delayed enforcement until starvation set in. But doing this per process is not possible with a unified VM and buffer cache, unless all file I/O occurs via mmap(), rather than kernel read/write calls (not possible to do, because of struct fileops, since not all vnodes are created equal in FreeBSD; sockets are a particularly problematic area). You could make this approach even more complex, in an attempt to ensure fairness by raising the quota on a per reference basis, but that's exploitable. If we are talking web traffic here, then the enforcement of working set size should probably take into account how close the quota is to the file size: if the quota is 800k, and the file is 801k, then it probably makes sense to give in to the process, and load the extra page to avoid thrashing. This is probably calculable as a percentage of the remaining system resources, once the system is over the high watermark, but below total starvation. Realize that the normal approach to this problem is to simply trust LRU and the locality of reference model. I don't think that anything you can think of (short of packing in more RAM) can possibly prevent at least _some_ elbow in the performance at starvation. But on the other hand the OS can't lock the pages in memory until they are read, since passing the fd to poll() isn't a promise to read since this may lead to DOS attacks, or alternatively processes being unexpectedly killed for hitting RLIMIT_MEMLOCK. Yes. I _am_ assuming that your access model used by your application is relatively uniform. If everything doesn't go through the same access path, all bets are off. This is going to be true of any asymmetric application under resource starvation conditions, though, sho I view this as a problem og you shooting yourself in the foot: it's your foot, and you can do what you want with it, including shooting it. This should mean that it's robust in the face of a DOS attack (given that the code path is uniform), but not robust in the face of being badly implemented. I'd have to say that there, too, you have no defense, but since it's your own fault, as ye sow, so shall ye reap. 8-).
Re: In-Kernel HTTP Server (name preference)
On Monday 18 February 2002 07:54 pm, Peter Wemm wrote: Mike Silbersack wrote: On Mon, 18 Feb 2002, Hiten Pandya wrote: hi all, As to conclude this thread (for me.), I have come to the decision of actually starting a project for making a BSD Licensed in-kernel HTTPd server. The project will be on SourceForge.net. As you all know, that when starting a project, a name is needed for project; I completely out of ideas, and I have literally no creative skills. :) If you want to be really useful, I have a better first step for you. :) Common wisdom seems to be that Apache is slow, other httpds are faster, custom ones are fastest. However, I don't think I've actually seen any comparisons since this one of thttpd vs others: http://www.acme.com/software/thttpd/benchmarks.html Before starting work on a kernel httpd, you might wish to run similar benchmarks (with perhaps only 5 different httpds) to see what the current performance of FreeBSD is; it may turn out that some limitation in the TCP stack is hit even by userland httpds, and your effort would be better spent on fixing that first. The problem is that our threads implementation sucks. The moment that thttpd has to do an actual disk read on freebsd, the whole thing comes to a screeching halt. Threaded http servers do not stand up to real-world loads on freebsd, unless there are very specially constructred scenarios in place.. ie: everything is in ram, no FS calls ever block, etc. Cheers, -Peter I don't suppose it matters much than thttpd isn't threaded. It's a non-blocking server that uses it's own abstraction layer over select/poll/kevent called fdevent. It also maintains an mmap'd cache of frequently accessed files. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
On Mon, Feb 18, 2002 at 06:54:01PM -0800, Peter Wemm wrote: Mike Silbersack wrote: On Mon, 18 Feb 2002, Hiten Pandya wrote: hi all, As to conclude this thread (for me.), I have come to the decision of actually starting a project for making a BSD Licensed in-kernel HTTPd server. The project will be on SourceForge.net. As you all know, that when starting a project, a name is needed for project; I completely out of ideas, and I have literally no creative skills. :) If you want to be really useful, I have a better first step for you. :) Common wisdom seems to be that Apache is slow, other httpds are faster, custom ones are fastest. However, I don't think I've actually seen any comparisons since this one of thttpd vs others: http://www.acme.com/software/thttpd/benchmarks.html Before starting work on a kernel httpd, you might wish to run similar benchmarks (with perhaps only 5 different httpds) to see what the current performance of FreeBSD is; it may turn out that some limitation in the TCP stack is hit even by userland httpds, and your effort would be better spent on fixing that first. The problem is that our threads implementation sucks. The moment that thttpd has to do an actual disk read on freebsd, the whole thing comes to a screeching halt. Threaded http servers do not stand up to real-world loads on freebsd, unless there are very specially constructred scenarios in place.. ie: everything is in ram, no FS calls ever block, etc. I don't believe tHttpd is threaded. http://www.acme.com/software/thttpd/notes.html on the section regarding non-blocking I/O: The fourth generation. One process only. No non-portable threads/LWPs. Sends multiple files concurrently using non-blocking I/O, calling select()/poll()/kqueue() to tell which ones are ready for more data. Speed is excellent. Memory use is excellent. Portability is excellent. Examples of this generation: Spinner, Open Market, and thttpd. Perhaps Apache will switch to this method at some point. I really can't understand why they went with that complicated pre-forking stuff. Using non-blockijng I/O is just not that hard. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Dominic To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
Apache will switch to this method at some point. I really can't understand why they went with that complicated pre-forking stuff. Using non-blockijng I/O is just not that hard. As mentioned previously, due to the blocking semantics of file I/O on unix, single process servers will only provide peak throughput if everything is resident. By pre-forking, data can continued to be served if one process blocks on file I/O. Apache already handles multiple connections within a process, so it does something like this already. -Kip To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
Hey, On Tue, Feb 19, 2002 at 09:19:56AM -0800, Kip Macy wrote: Apache will switch to this method at some point. I really can't understand why they went with that complicated pre-forking stuff. Using non-blockijng I/O is just not that hard. As mentioned previously, due to the blocking semantics of file I/O on unix, single process servers will only provide peak throughput if everything is resident. By pre-forking, data can continued to be served if one process blocks on file I/O. Apache already handles multiple connections within a process, so it does something like this already. Yes.. but if your using non-blocking IO for both the disc and network read/writes, this no longer applies. If I understand correctly in normal operation a server like tHttpd simply blocks on kevent() and when a descriptor becomes available for servicing it handles this occurance, or occurances since a single kevent() call can return more than a single event and then goes back to blocking. Reads and writes don't block if they don't complete, you simply get another event when the descriptor becomes available again. Am I wrong? -Kip To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Dominic To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
* Dominic Marks [EMAIL PROTECTED] [020219 09:53] wrote: Hey, On Tue, Feb 19, 2002 at 09:19:56AM -0800, Kip Macy wrote: Apache will switch to this method at some point. I really can't understand why they went with that complicated pre-forking stuff. Using non-blockijng I/O is just not that hard. As mentioned previously, due to the blocking semantics of file I/O on unix, single process servers will only provide peak throughput if everything is resident. By pre-forking, data can continued to be served if one process blocks on file I/O. Apache already handles multiple connections within a process, so it does something like this already. Yes.. but if your using non-blocking IO for both the disc and network read/writes, this no longer applies. If I understand correctly in normal operation a server like tHttpd simply blocks on kevent() and when a descriptor becomes available for servicing it handles this occurance, or occurances since a single kevent() call can return more than a single event and then goes back to blocking. Reads and writes don't block if they don't complete, you simply get another event when the descriptor becomes available again. Am I wrong? Yes, you are wrong. Disk IO can't be done in a non-blocking manner. If the kernel doesn't have the portion of the file you wish to read in the buffer cache then the process will block waiting. There is simply nothing you can do about this other than to offload that blocking into another process context via kernel threads, posix aio or kses. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
On Tue, Feb 19, 2002 at 10:00:04AM -0800, Alfred Perlstein wrote: * Dominic Marks [EMAIL PROTECTED] [020219 09:53] wrote: Hey, On Tue, Feb 19, 2002 at 09:19:56AM -0800, Kip Macy wrote: Apache will switch to this method at some point. I really can't understand why they went with that complicated pre-forking stuff. Using non-blockijng I/O is just not that hard. As mentioned previously, due to the blocking semantics of file I/O on unix, single process servers will only provide peak throughput if everything is resident. By pre-forking, data can continued to be served if one process blocks on file I/O. Apache already handles multiple connections within a process, so it does something like this already. Yes.. but if your using non-blocking IO for both the disc and network read/writes, this no longer applies. If I understand correctly in normal operation a server like tHttpd simply blocks on kevent() and when a descriptor becomes available for servicing it handles this occurance, or occurances since a single kevent() call can return more than a single event and then goes back to blocking. Reads and writes don't block if they don't complete, you simply get another event when the descriptor becomes available again. Am I wrong? Yes, you are wrong. Disk IO can't be done in a non-blocking manner. If the kernel doesn't have the portion of the file you wish to read in the buffer cache then the process will block waiting. There is simply nothing you can do about this other than to offload that blocking into another process context via kernel threads, posix aio or kses. Thanks for the lesson! -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ -- Dominic To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
Alfred Perlstein wrote: Disk IO can't be done in a non-blocking manner. If the kernel doesn't have the portion of the file you wish to read in the buffer cache then the process will block waiting. There is simply nothing you can do about this other than to offload that blocking into another process context via kernel threads, posix aio or kses. On SVR4, an attempt to access a non-resident page via a non-blocking fd will result in a fault for that page being scheduled, while the call returns to the user process with an EWOULDBLOCK. A subsequent attempt to read it gets the paged in data, and then works as expected. The poll() call takes note of these outstanding page-in requests, and uses them to satisfy poll on a readable condition, so you can e.g. attempt the read, get that it would block, and then poll on readable on the fd, to avoid buzz-looping the process. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
Julian Elischer [EMAIL PROTECTED] wrote: I can suggest using a netgraph module for the work as it can be connected to a netgraph ksocket node to receive the requests (jdp made all the changes needed to allow this to be done). Another way would be to implement it as an accept filter which knows how to handle simple requests but drops anything more complicated down to a userland web server -- an unmodified Apache would be able to do the latter, since it already supports accept filters. Some way of configuring it is still needed, though... Tony. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
Dominic Marks [EMAIL PROTECTED] http://www.acme.com/software/thttpd/notes.html on the section regarding non-blocking I/O: The fourth generation. One process only. No non-portable threads/LWPs. Sends multiple files concurrently using non-blocking I/O, calling select()/poll()/kqueue() to tell which ones are ready for more data. Speed is excellent. Memory use is excellent. Portability is excellent. Examples of this generation: Spinner, Open Market, and thttpd. Perhaps Apache will switch to this method at some point. I really can't understand why they went with that complicated pre-forking stuff. Using non-blockijng I/O is just not that hard. Apache-2.0 will use a combination of in-process threading and pre-forking by default, but the IO architecture has some scope for adding non-blocking IO in the future. The reasons for preforking are that it makes programming server extensions much easier, especially when you consider things like database libraries that don't provide a non-blocking API, etc. (Other bits of Apache are designed to be simple, like the memory management.) Another thing in preforking's favour is that it makes the server as a whole MUCH more robust -- a child process can blow up without taking down the server -- and again this has advantages with unreliable server extensions. Tony. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
Terry Lambert [EMAIL PROTECTED] wrote: On SVR4, an attempt to access a non-resident page via a non-blocking fd will result in a fault for that page being scheduled, while the call returns to the user process with an EWOULDBLOCK. A subsequent attempt to read it gets the paged in data, and then works as expected. The poll() call takes note of these outstanding page-in requests, and uses them to satisfy poll on a readable condition, so you can e.g. attempt the read, get that it would block, and then poll on readable on the fd, to avoid buzz-looping the process. How does it deal with the situation that the machine's working set has exceeded memory? If the web server is dealing with lots of concurrent connections it may have to block in poll() waiting for (say) a thousand pages to be brought in, then in the process of dealing with them after the poll() returns some of the pages may get re-used for something else making read() on a readable fd return EWOULDBLOCK again. But on the other hand the OS can't lock the pages in memory until they are read, since passing the fd to poll() isn't a promise to read since this may lead to DOS attacks, or alternatively processes being unexpectedly killed for hitting RLIMIT_MEMLOCK. I can't see a good way of avoiding these semantic problems without changing to a completely different kernel API like KSE. Tony. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
hi all, As to conclude this thread (for me.), I have come to the decision of actually starting a project for making a BSD Licensed in-kernel HTTPd server. The project will be on SourceForge.net. As you all know, that when starting a project, a name is needed for project; I completely out of ideas, and I have literally no creative skills. :) I wanted some names, which could be used for the project. Also, because this code, will be coming back to the FreeBSD community, people should have the chance to decide on the name. Once I have got enough names, I will count the vote on them, and choose the final name, if that is OK with everyone. I am supplying some of the names which came out of my and from my un-creative mind. ;) To vote, give a +1 for yes, and -1 for no. o fhttpd (I donno what the 'f' is for..) o quarx o starling o rattlesnake If someone has better ideas, please do not hesitate to pass me your suggestions. Thanks, Regards, -- Hiten Pandya -- [EMAIL PROTECTED] msg31952/pgp0.pgp Description: PGP signature
Re: In-Kernel HTTP Server (name preference)
Hiten Pandya wrote: As to conclude this thread (for me.), I have come to the decision of actually starting a project for making a BSD Licensed in-kernel HTTPd server. The project will be on SourceForge.net. [ ... ] To vote, give a +1 for yes, and -1 for no. o fhttpd (I donno what the 'f' is for..) o quarx o starling o rattlesnake If someone has better ideas, please do not hesitate to pass me your suggestions. ng_httpd (Assunimg it uses netgraph). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
hi all, As to conclude this thread (for me.), I have come to the decision of=20 actually starting a project for making a BSD Licensed in-kernel HTTPd=20 server. The project will be on SourceForge.net. I, too, have started one of these, already have it loading, but not doing anything :) merely as an educational tool, I DEMAND that no one abort their project merely cuz I've started one :) I'd be interested in discussion, thought sharing, and having parallel friendly projects, but think maybe it should be moved off this list? I can supply a mailing list or would be happy to do the cc dealie :) As you all know, that when starting a project, a name is needed for project; I completely out of ideas, and I have literally no creative skills. :) I've no creativity, mines in my cvs repository as fbsdkhttpd and registering itself to the kernel as khttpd :) I'm assuming it's safe to use possibly conflicting names in kernel registration, as it's unlikely someone would load two different implementations of a khttpd? maybe it'll be useful to an embedded system developer somewhere (I know my cable modem has a webserver built in for diagonistics and admin) snip -Erik [EMAIL PROTECTED] [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
will it be able to send pages from the filesystem or just preloaded pages? How will you configure it? I can suggest using a netgraph module for the work as it can be connected to a netgraph ksocket node to receive the requests (jdp made all the changes needed to allow this to be done). It also gives you a way of implementing as many servers as you need on a single machine. no idea on the name though On Mon, 18 Feb 2002, Hiten Pandya wrote: hi all, As to conclude this thread (for me.), I have come to the decision of actually starting a project for making a BSD Licensed in-kernel HTTPd server. The project will be on SourceForge.net. As you all know, that when starting a project, a name is needed for project; I completely out of ideas, and I have literally no creative skills. :) I wanted some names, which could be used for the project. Also, because this code, will be coming back to the FreeBSD community, people should have the chance to decide on the name. Once I have got enough names, I will count the vote on them, and choose the final name, if that is OK with everyone. I am supplying some of the names which came out of my and from my un-creative mind. ;) To vote, give a +1 for yes, and -1 for no. o fhttpd (I donno what the 'f' is for..) o quarx o starling o rattlesnake If someone has better ideas, please do not hesitate to pass me your suggestions. Thanks, Regards, -- Hiten Pandya -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
Hi, On Mon, Feb 18, 2002 at 11:12:54AM -0800, Julian Elischer wrote: no idea on the name though forked stick? It fork's and stick pages out a socket. A graph is a forked stick diagram. The daemon as a forked stick. And is should be able to serve more pages than you can shake a forked stick at... Yes, it's been a bad day. Why do you ask? -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
On Mon, 18 Feb 2002, Hiten Pandya wrote: hi all, As to conclude this thread (for me.), I have come to the decision of actually starting a project for making a BSD Licensed in-kernel HTTPd server. The project will be on SourceForge.net. As you all know, that when starting a project, a name is needed for project; I completely out of ideas, and I have literally no creative skills. :) If you want to be really useful, I have a better first step for you. :) Common wisdom seems to be that Apache is slow, other httpds are faster, custom ones are fastest. However, I don't think I've actually seen any comparisons since this one of thttpd vs others: http://www.acme.com/software/thttpd/benchmarks.html Before starting work on a kernel httpd, you might wish to run similar benchmarks (with perhaps only 5 different httpds) to see what the current performance of FreeBSD is; it may turn out that some limitation in the TCP stack is hit even by userland httpds, and your effort would be better spent on fixing that first. FWIW, I have no ideas for the name of the benchmarking project. :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
On Mon, Feb 18, 2002 at 06:02:54PM +, Hiten Pandya wrote: If someone has better ideas, please do not hesitate to pass me your suggestions. how about: actually write the code before annoying -hackers. how is JFS coming along... -- - bill fumerola / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] - my anger management counselor can beat up your self-affirmation therapist To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
Mike Silbersack wrote: On Mon, 18 Feb 2002, Hiten Pandya wrote: hi all, As to conclude this thread (for me.), I have come to the decision of actually starting a project for making a BSD Licensed in-kernel HTTPd server. The project will be on SourceForge.net. As you all know, that when starting a project, a name is needed for project; I completely out of ideas, and I have literally no creative skills. :) If you want to be really useful, I have a better first step for you. :) Common wisdom seems to be that Apache is slow, other httpds are faster, custom ones are fastest. However, I don't think I've actually seen any comparisons since this one of thttpd vs others: http://www.acme.com/software/thttpd/benchmarks.html Before starting work on a kernel httpd, you might wish to run similar benchmarks (with perhaps only 5 different httpds) to see what the current performance of FreeBSD is; it may turn out that some limitation in the TCP stack is hit even by userland httpds, and your effort would be better spent on fixing that first. The problem is that our threads implementation sucks. The moment that thttpd has to do an actual disk read on freebsd, the whole thing comes to a screeching halt. Threaded http servers do not stand up to real-world loads on freebsd, unless there are very specially constructred scenarios in place.. ie: everything is in ram, no FS calls ever block, etc. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
On Mon, 18 Feb 2002, Peter Wemm wrote: The problem is that our threads implementation sucks. The moment that thttpd has to do an actual disk read on freebsd, the whole thing comes to a screeching halt. Threaded http servers do not stand up to real-world loads on freebsd, unless there are very specially constructred scenarios in place.. ie: everything is in ram, no FS calls ever block, etc. Cheers, -Peter Well, a benchmark should be able to show that, assuming that a set of files larger than physical ram is used. I wasn't intending to imply that thttpd was necessarily superior to Apache, I just would be interested to see how various web servers compare today. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
