WebObjects/Web Applications/Deployment/Deployment

From Wikibooks, open books for an open world
< WebObjects‎ | Web Applications/Deployment
Jump to navigation Jump to search



Auto Recover : checked

Caching Enabled: checked

Lifebeat Interval: 30

Additional Arguments

-WODirectConnectEnabled false 
-EOAdaptorDebugEnabled false 
-WOHost hostname.com
-Xms128m -Xmx600m

Instance RAM Calculator XMnnnx (Server RAM MB - RAM for OS) / Instances = per instance RAM


Name: WOApp

Starting Port: N/A

Time Allowed For Startup: in seconds

Phased Startup: checked

Adaptor: WODefaultAdaptor

Minimum Adaptor threads1: 2 ( Adaptor threads is the number of threads to spawn to service your requests.)

Maximum Adaptor threads2: 8

Adaptor threads:

Listen Queue Size: 2

Project Search Path: ()

Session TimeOut (sec)3: 1

Statistics Page Password: N/A

Load Balancing and Adaptor Settings

Load balancing scheme: Round Robin

1. Adaptor threads is the number of threads to spawn to service your requests.

2. IIRC he said about 7-8 worker threads and 2-3 listen queue ones. Of course that depends on your app and what average requests are doing etc etc. But above that limit, if the app slows, the requests pile up to where it has no hope of meaningful recovery (the app may recover, but the users have gotten an error message long before).

Based on Max's comments, I have set the listen queue size to 2, minimum adaptor threads to 2, and maximum adaptor threads to 4 on my deployed WO apps. Yes, these seem extremely low compared with the defaults, but as Chuck (and Max) stated, higher values can cause poor performance at high loads. With these low settings, you'll get a warning at app startup, but ignoring this warning hasn't caused any obvious problem.

3. You can adjust your session timeout dynamically. We allow 5 minutes to login, but once you login, we bump it back up to 3600. That way we don't have a bunch of stale sessions triggered by web robots.