Re: [AOLSERVER] config confusion
I know about the select loop thingy, but this was just for static content. What I'm suggesting is to use threads to generate dynamic content (on multiple processors), then, if the output will fit into a socket buffer, send it by the thread. Then the thread can immediately go back to handle another request. If the output won't fit into a socket buffer, pass it to the select loop where the output can be drained at whatever rate the user will accept it. Personally, I don't care if the select loop thread uses multiple processors. The content generation (the hard part) will use multiple cpus. It would be interesting to have a stat for how often threads are blocked while writing to the socket. J On Saturday, September 29, 2001, at 03:59 AM, Jim Wilcoxson wrote: 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.) AOLserver 2.3.3 had this -- it was called select-loop serving. It was taken out because it didn't use the other processors in a multiprocessor machine; the threads do a better job of that.
Re: [AOLSERVER] config confusion
On Sat, 29 Sep 2001, Jim Wilcoxson wrote: Personally, I don't care if the select loop thread uses multiple processors. The content generation (the hard part) will use multiple cpus. That's fair, but then you don't have as many processors, nor as much traffic as does AOL -- AOLserver's main customer. I don't think the AOL core team is likely to implement or accept a select loop implementation that doesn't make good use of the hardware. Of course, when we all get through with all the other stuff on our plates, we can always put something in OpenNSD.
Re: [AOLSERVER] config confusion
I like the queueing behavior rather than Server Busy. If it takes a long time, people will know the server is busy and can either wait or not. If it spits back Server Busy, they have to keep hitting Reload. One good thing about having a connection queue separate from the listen queue is that it can be used for better wait time statistics. On Saturday, September 29, 2001, at 08:41 AM, Dossy wrote: I'm still curious as to why the busy message was gotten rid of in the AOLserver 3.x tree That facility was mostly provided for internal high-traffic sites within AOL when the sites ran 2.3.3, which couldn't keep up with the load. The 3. x version was so much faster that the feature was no longer necessary. It didn't always work, either, and it was a real pain to debug.
Re: [AOLSERVER] config confusion
Jim this writeup is great. What you write coincides with my own analyses two months ago when upgrading nsunix to AOLserver 3.3. 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. 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 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. 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
Re: [AOLSERVER] config confusion
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
Re: [AOLSERVER] config confusion
On 2001.09.29, Jim Wilcoxson [EMAIL PROTECTED] wrote: 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. As a webmaster, in the worst case scenario, I'd rather users think that the site is slow rather than the site being down. maxconnections maxthreads means that the extra connections should be queued, rather than simply not answered, which would make the site appear to be down. I'm still curious as to why the busy message was gotten rid of in the AOLserver 3.x tree ... an extra single thread whose sole responsibility is to answer connections that are exceeding maxthreads would be nice. This way, users don't sit in the queue too long (or, the queue doesn't fill up and the additional users get the connection refused instead). Some people have posted that their server hangs under a load. You may want to try decreasing maxthreads and maxconnections to stress-test the resuming mechanism. A typical server with the default configuration of maxconnections=100 would probably never get in this resuming state. Or an alternative to avoid the problem would be to keep increasing maxconnections until you never see the resuming message in your logs. Interestingly enough, on my Netscape Enterprise Server webservers at work (which are also multi-threaded) I believe the default connection queue size is 512. I wonder what effect on the hanging problem it would have if you set maxconnections to 512 and maxthreads to 256. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/
Re: [AOLSERVER] config confusion
On 2001.09.29, Jim Wilcoxson [EMAIL PROTECTED] wrote: 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. Are you saying that maxconnections isn't setting the socket listen queue size? -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/
Re: [AOLSERVER] config confusion
At 05:42 AM 9/29/01, you wrote: On 2001.09.29, Jim Wilcoxson [EMAIL PROTECTED] wrote: 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. Are you saying that maxconnections isn't setting the socket listen queue size? -- Dossy I say that maxconnections sets the number of connections that can be accepted, backlog sets the socket listen queue size, I don't know what causes the server to hang. That's what we want to find out! http://www.city-net.com/abbottandcostellofc/whoscrip.htm Jerry Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980 Berkeley, CA 94709 Fax: (877) 311-8688
Re: [AOLSERVER] config confusion
I agree with Jerry's explanation. -Jim At 05:42 AM 9/29/01, you wrote: On 2001.09.29, Jim Wilcoxson [EMAIL PROTECTED] wrote: 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. Are you saying that maxconnections isn't setting the socket listen queue size? -- Dossy I say that maxconnections sets the number of connections that can be accepted, backlog sets the socket listen queue size, I don't know what causes the server to hang. That's what we want to find out! http://www.city-net.com/abbottandcostellofc/whoscrip.htm Jerry Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980 Berkeley, CA 94709 Fax: (877) 311-8688
Re: [AOLSERVER] config confusion
+-- On Sep 29, Jim Wilcoxson said: 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). Before 3.4, nsd would return a 503 server busy if it had maxconnections already. In 3.4, it just stops calling accept. So it was more useful before 3.4. Also, the kernel will only buffer a limited number of the number of un-accept()ed connections. If you want to buffer more than that many, you need to set maxconnections larger. maxdropped is unusual. maxdropped was perhaps also more useful before 3.4. If your server fell far behind, then it was probably in some hosed state and needed to be restarted.
Re: [AOLSERVER] config confusion
On Saturday, September 29, 2001, at 03:59 AM, Jim Wilcoxson wrote: 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.) AOLserver 2.3.3 had this -- it was called select-loop serving. It was taken out because it didn't use the other processors in a multiprocessor machine; the threads do a better job of that.
Re: [AOLSERVER] config confusion
On Saturday, September 29, 2001, at 08:41 AM, Dossy wrote: I'm still curious as to why the busy message was gotten rid of in the AOLserver 3.x tree That facility was mostly provided for internal high-traffic sites within AOL when the sites ran 2.3.3, which couldn't keep up with the load. The 3. x version was so much faster that the feature was no longer necessary. It didn't always work, either, and it was a real pain to debug.
