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: Chuck Hill <email@hidden>
- Date: Wed, 15 Feb 2006 12:09:42 -0800
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