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 PROTECTED]> 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 protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
