WebObjects/Web Applications/Deployment/Deployment

WO DEPLOYMENT BLACK ART CHEAT SHEET

NEW INSTANCE DEFAULTS

Auto Recover : checked

Caching Enabled: checked

Lifebeat Interval: 30

Additional Arguments

-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

APPLICATION SETTINGS

Name: WOApp

Starting Port: N/A

Time Allowed For Startup: in seconds

Phased Startup: checked

Adaptor: WODefaultAdaptor

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

Maximum Adaptor threads²: 8

Adaptor threads:

Listen Queue Size: 2

Project Search Path: ()

Session TimeOut (sec)³: 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.