I made this suggestion a while ago (sending the output in an output thread). One argument against it at the time is that on a multi-processor machine, you may not be able to take advantage of all the processors. However, input and output spooling is not CPU intensive, so I don't think it's all that necessary to have multiple input and output threads running.
As far as memory considerations, the same amount of memory is going to be needed whether there are N threads, each spooling 1 output request, or 1 output process spooling all N output requests. An alternative is to configure your socket output buffer size so that the majority of your output responses will fit. You'll get the same basic effect as single-process output spooling, but your OS will do all of the work. Jim > > That got me to thinking about how AOLserver works on responses - > > So a single thread handles the receiving of the request - which makes > perfect sense on requests < around 32K or so, which is probably 99.5% of them. > > What about on output? In other words, a request comes in, the single IO > thread reads it, then once its finished it gets handed out to a thread for > processing. What happens when its done? Does that thread do all the output > on its own? In my imaginary world, I would love it if the thread handed the > output data back to the central I/O thread, which could return it to the > client at its own pace. AOLserver's I/O thread would get huge in terms of > memory for doing this, but it _should_ act as a powerful connection > multiplexor - you can imagine possibly 2x maxthreads connecting, and if the > individual threads finished off the connections quickly, returning data to > the central thread - well, it would pretty much obviate the need for caching > proxy servers in front of AOLserver, right? > > If it already works this way - then architectural bits like that should be > showcased so that more users choose AOLserver. If it doesn't - does what I > say make sense? Would it have too much memory impact? > > Sorry for the ramble, your previous response and that URL got me to thinking > about an idea I had had before... > > On Tue, 11 May 2004 15:35:40 -0400, Nathan Folkman <[EMAIL PROTECTED]> wrote: > > >Exactly. The idea is to keep I/O events isolated to the main driver > >thread, which in theory should be more efficient. The goal is to not tie > >up connection threads, and have them sitting idle waiting for I/O. > > > >This model is kind of the best of both worlds - single-threaded event > >loop that accepts connections and consumes the request, and > >multi-threaded connection threads to do the actual work of the request. > > > >The ideas are similar to work that's discussed here: > > > > http://www.eecs.harvard.edu/~mdw/proj/seda/ > > > >At least this is how I remember things... ;-) > > > >- Nathan > > > > > >Tom Jackson wrote on 5/11/2004, 3:23 PM: > > > > > You have to read all the data anyway, but > > > now the POSTed data is read in so you don't have a tcl procedure slowly > > > reading data and controlling the connection. > > > > > >-- > >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. > > A > > > -- > 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.
