|
Thanks,
My parameters are (bigger):
HTTP Adaptor Settings:
Load Balancing scheme: Round Robin
Send Timeout: 1200
Receive Timeout: 1200
Connect Timeout: 3600
Connection Pool Size:16
(other parameters are not set, blank field in Monitor)
Application settings:
Adaptor: WODefaultAdaptor
Minium Adaptor threads: 16
Maximum Adaptor threads: 256
Adaptor threads: 8
Listen Queue Size: 128
Project Search Path: ()
Session TimeOut (sec): 2500
I tried to set something similar to your parameters but then on direct action half of the time the user get a page with:
<html><body><strong>No error</strong></body></html>
I tried to identify who generates this page but without success.
The page seems related to an http error 500.
Is any way to avoid the adaptor to give the request to another instance if one instance is too slow to respond because this seems no helping because at the end it causes a "Session timeout" error.
I need also to say that when the user get a untimely "Session Timeout", there is not waiting time (We got the session timeout just after the click on a button). I would expect some retrying before returning an Session timeout error if it is due to a instance
not responding.
Dominique
On Oct 11, 2013, at 9:54 PM, Klaus Berkling < email@hidden> wrote:
On Oct 11, 2013, at 12:27 PM, Chuck Hill < email@hidden> wrote:
In addition to what Chuck said, check the adaptor threads and listen
queue size in the Application settings. Typically I used min 10, max 20,
queue 20. This is very app specific. It's better to let connections queue
up than to let them go to a different instance.
Well,
up to a point. Beyond that the user's think there is a problem and
start
clicking again or reloading the page. Then your app gets overloaded
and
no one gets any service. It is very app specific, but I would usually
advocate
lower numbers. Your app, I know, is "special". ;-)
For that special app I'm using 20/40/40 and yes it makes no sense but it seems to work best this way.
_______________________________________________
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
|