Hide Forgot
++ This bug is a clone of bug 778947 ++ Affects: Documentation (Ref Guide, User Guide, etc.) Date of First Response: 2009-06-22 06:14:13 project_key: SOA Requesting addition of a performance tuning section to the documentation. I'm not picky where it goes, maybe chapter 2 of getting started guide, maybe chapter 7 of programmer's guide, maybe some place different. For a start, I'd like to put at least these things in the tuning section: 1.) http://www.jboss.org/community/wiki/JBossESBPerformanceTuning 2.) Discussion of InVMRegistryInterceptor, CachingRegistryInterceptor - especially the latter which is not enabled by default 3.) Discussion of how to horizontally scale 4.) Discussion of removing ESB Management Console or keeping JMXDATA table clean (https://jira.jboss.org/jira/browse/SOA-1393) 5.) Discussion of using tomcat-native for increased performance specifically for EBWS and new HttpProvider: http://www.jboss.org/community/wiki/HowToAddAprToJBoss 6.) Add info from Martin's tuning guide (linked in comments)
Have one additional point to be added to the tuning section: 3.) Discussion of horizontal scaling For example, maybe it would include a paragraph or two like this: If tuning the performance of a given ESB instance is still not sufficient for the workload it needs to handle, one should consider horizontal scaling of the ESB. For example, one could deploy two SOA-P instances side by side. To handle this from a client perspective, one could deploy the same service on both nodes but only deploy the gateway on one node which would allow the ESB to handle the load balancing. Another alternative would be to deploy the gateway on both nodes. The best way to handle the multiple gateways from an ESB client perspective would depend on the gateway transport. For JMS, one could use distributed queues on the SOA-P instances. For HTTP, one could configure a load balancer (Apache mod_* or hardware based) to load balance between the HTTP gateways. This simple mechanism of horizontally scaling SOA-P instances can substantially increase the workload that can be processed in a given environment.
IMHO 1) needs some editing. It has no sense to create listeners with so many threads (100). It doesn't have any sense to setup more threads than number of CPU cores.
1) certainly needs editing and there is already a task in JBESB to handle it, JBESB-1937. As for the number of threads, there are times when more than the number of cores does make sense, for example when executing synchronous services (not a good idea for performance, but sometimes necessary) or IO intensive operations.
Link: Added: This issue depends JBESB-1937
Added request to include discussion of tomcat-native for HTTP improvements (EBWS, HttpProvider)
Affects: Added: [Documentation (Ref Guide, User Guide, etc.)]
Should this be moved to 5.0.1 or later? Considering JBESB-1937 has been moved back.
If JBESB-1937 isn't going in until ESB 4.8 can someone highlight which (if any) of the mentioned references are suitable for inclusion "as is" in the SOA 5.0.1 documentation possibly as a standalone "Performance Tuning Guide".
Can I have some feedback on my previous comment so I can schedule docs work for 5.0.1 ?
Closing as out of date.