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
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
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
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
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
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
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
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
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 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.
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
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
12 matches
Mail list logo
