> If I understand your question then my guess as to the advantage of > accepting connections even when there are no threads available is thus: > > 1. We know it's the typical case that you can have 100 connections and only > ten threads, so by default you have to be able to accept more connections > than threads.
But it doesn't seem to buy anything to have users waiting on a connection queue vs. waiting on the socket listen queue, except they have a different message on their browser status line. (Assuming they will wait < 30 seconds --the usual browser timeout) > 2. Connections can block for i/o (waiting for the 300 baud dial up user using > a 20 year old trs-100, so you would want a thread to be able to handle > more than one connection >From my reading, 1 thread handles 1 connection. What would be cool is if returning data to the user could go through a single-thread, multi-connection select loop if it would overflow the socket output buffer. Then an expensive TCL thread wouldn't be tied up waiting for a 300 baud modem to drain the server's response. (Another reason why more threads need to be configured and it's hard to tune.) > 3. If you aren't being slashdotted and the high traffic is temporary, than > accepting the connection and holding onto it until a thread becomes > available probably keeps the browser from timing out more often than > in the case where the connection isn't accepted until a thread becomes > available. Yeah, I can sort of see that. But this is similar to the "server startup storm" avoidance in 3.X, where it doesn't start listening until it's all ready to go - the theory being that if it takes 30 seconds to start the server and you queue 1000 requests during that time, it may take a long time to clear the backlog. It's a choice between being sluggish on 1000 (or 5000, depending on how fast they continue to come in) requests or rejecting the 1000 requests and then providing good service to the new requests. Having a connection queue allows "slushy" service over a longer period rather than browser timeouts. My experience is that users will click the link/button again if they get too impatient (usually less than 10 seconds), so accepting the connection and delaying more than 30 seconds--the typical browser timeout--may not make sense. I dunno... I know with 2.3.3 it has been useful to have the server hold new connections during a restart, because the thing crashes 10 times/day. Users with accepted connections see a server restart, but new users coming in during the restart just see a delay during the 10-15 second startup. With 3.4, connected users will still see a reset and new requests will get a "The page cannot be displayed" error during startup. I do understand the reasoning behind this change though... Jim > > >I don't quite understand the value of accepting connections even > >though there is no thread available to service the request (this > >occurs if maxconnections > maxthreads). From my point of view as a > >webmaster, I will probably set maxconnections and maxthreads equal. > >This way, if a browser hits our site and no thread is available, the > >user will see "contacting blah.com" during the delay and assume there > >is some network problem. If I set maxconnections > maxthreads and > >maxthreads is too low, users will see "blah.com contacted, waiting for > >reply" and it'll look like our site is slow. Okay - a bit deceitful. > > > Jerry > > ======================================================== > Jerry Asher [EMAIL PROTECTED] > 1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980 > Berkeley, CA 94709 Fax: (877) 311-8688 >
