Re: Listen Queue Size Setting & Concurrent Request Handling
Re: Listen Queue Size Setting & Concurrent Request Handling
- Subject: Re: Listen Queue Size Setting & Concurrent Request Handling
- From: Eric Stewart <email@hidden>
- Date: Wed, 15 Feb 2006 16:32:41 -0500
By WOWorkerThread settings you are referring to "Minimum Adaptor
threads" and "Maximum Adaptor threads" settings under application
settings?
- Eric
On 2/15/06, Chuck Hill <email@hidden> wrote:
> Hi Eric,
>
> On Feb 15, 2006, at 10:48 AM, Eric Stewart wrote:
>
> > I'm a little confused about the "Listen Queue Size" setting in the
> > application setting.
>
> It is not exactly transparent. :-) My understanding (which may be
> flawed):
>
> > If I understand this right. This is the total
> > number of requests that can wait on an instance to accept and process.
> >
> I think it is the number of requests that an instance can queue up
> waiting for an available WOWorkerThread. Out of the box, these start
> at 16 and increase to 256.
>
>
> > Lets say I set the queue size to 1. So if you have 2 instances of an
> > app running and you get 4 requests simultaneously, then two will be
> > processed immediate, and one will sit in the first instances queue and
> > the other will sit in the second instances queue.
> >
> No. Two will be processed immediately and two will be in
> WOWorkerThreads, waiting for their turn to run. The listen queue
> will be empty.
>
>
> > Now if 6 requests come in simultaneously, then 2 will be processed, 2
> > will be queued and 2 will be rejectes (if the number of retries is set
> > to 0). Is this a correct assumption of how this setting works?
> >
> No, not with the default setting for the number of WOWorkerThread.
> All will go into WOWorkerThreads and the listen queue will still be
> empty.
>
>
> > If so, then wouldn't enabling concurrent request handling almost
> > eliminate the usefulness of the Listen Queue setting?
> >
> All it means is that more WOWorkerThreads will be active at the same
> time.
>
> My understanding of when this is useful:
> 1) Change the defaults for WOWorkerThread. Very few (none?) WO apps
> can recover from 256 simultaneous requests before the woadaptor hangs
> up on the instance or the user clicks Stop or refresh or something
> (see Broken pipe messages in the log). Probably a min and max of 4
> and 8 is a good place to start.
>
> 2) Drop the Listen Queue size down to some thing small, like 2. That
> way the total requests that can built up before being rejected is 10.
>
> This prevents overloading an instance to the point where it can't
> recover meaningfully for the user. With direct actions, it spreads
> the load. With component actions it produces "your session has
> expired" messages for the users and tells you that you are way, way
> late on upgrading the hardware or at least creating more instances
> (assuming you have space capacity in CPU/memory/IO).
>
>
> Chuck
>
> --
> Coming in 2006 - an introduction to web applications using WebObjects
> and Xcode http://www.global-village.net/wointro
>
> Practical WebObjects - for developers who want to increase their
> overall knowledge of WebObjects or who are trying to solve specific
> problems. http://www.global-village.net/products/practical_webobjects
>
>
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden