WO DEPLOYMENT BLACK ART CHEAT SHEET
NEW INSTANCE DEFAULTS
Auto Recover : checked
Caching Enabled: checked
Lifebeat Interval: 30
-WODirectConnectEnabled false -EOAdaptorDebugEnabled false -WOHost hostname.com -Djava.awt.headless=TRUE -Xms128m -Xmx600m
Instance RAM Calculator XMnnnx (Server RAM MB - RAM for OS) / Instances = per instance RAM
Starting Port: N/A
Time Allowed For Startup: in seconds
Phased Startup: checked
Minimum Adaptor threads1: 2 ( Adaptor threads is the number of threads to spawn to service your requests.)
Maximum Adaptor threads2: 8
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.