Certainly, look at things like thttpd and Chromium and khttpd et al - many of them run one thread, or just enough threads to cover all CPU's, so I don't think the multi-processor argument holds much water. A proxy server like Squid also runs as a single process, I believe regardless of the number of CPU's. as you say, I/O doesn't take up any CPU.
As for the socket buffer configuration hack...would that really work? Woudl that scale? My concern would be resource starvation attacks possible if someone requested a large response, but didn't actually 'take' any of the response - thus forcing the server to cache up a large file, possibly many of them. My thought would be that you'd need to be able to maybe page stuff to disk or whatever to be able to defend against that... And would that be taking kernel memory, or client memory...? Realistically, how large could one configure the socket output buffer? Could a solution like what we're talking about be developed as a drop-in replacement for nssock or something? On Wed, 12 May 2004 10:06:36 -0700, Jim Wilcoxson <[EMAIL PROTECTED]> wrote: >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. -- 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.
