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 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.