Yep, there are always cases where any given solution won't work well. Using the HTTP protocol to download a a 600MB CD image or to implement a movie server, is clearly different than average web usage. To display the _directory_ of the CD image, or download individual files, output spooling would be a win, IMO.
For fastpath (static file serving), reading a file into a memory buffer would seem to scale well for typical web size images: 250K or less, especially considering that fastpath already uses a memory cache. I can see 3 scenarios: 1. File is small: put it in the cache, leave it there after spooling 2. File exceeds cache size limit, but is less than 1MB: put it in the cache, delete it after spooling or make it expire "very soon" 3. File is huge: let the connection thread spool it, like it does now, and don't spool it, or My apologies for stomping on your topic. I do think the ability to handle other protocols is a good idea, esp for sites that need to integrate user registration with a lot of different packages. Jim > I don't think the read-the-whole-file-in-the-conn-thread solution scales > very well when faced with a directory of CD images or a distribution of > Debian packages :-) ... > > > On Thu, 2004-08-19 at 06:14, Jim Wilcoxson wrote: > > I guess I was unclear in my earlier note: > > > > 1. The HTTP driver thread reads all input for request, w/o blocking. > > My understanding is that this is now happening in AS 4 - great! > > > > 2. A conn service thread creates the output, either by running a TCL > > script, executing fastpath to read a file into memory, etc. This > > might do stats, file I/O, database I/O, etc., and may block. The > > result of this thread is a memory buffer. > > > > 3. The HTTP driver thread spools the memory buffer back to the client, > > w/o blocking. > > > > I wasn't suggesting that there should be no blocking in step 2, when > > the output is being created. That's why multiple connection service > > threads are needed. But the problem of a connection service thread > > being tied up while it spools a large page/image is eliminated. > > > > In the application of an image server, it would be nice if there could > > be one fastpath thread that did all non-blocking filesystem I/O > > (actually just reading is needed), or an asynchronous sendfile, but I > > agree with you that there are not good portable ways to do that yet. > > > > Jim > > ge. You can leave the Subject: field of your email blank. > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with > the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field > of your email blank. > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
