Xform performance tuning with respect to Weblogic Application Server

We deployed our complex Xforms in Tomacat and Web sphere Application server. The performance of the Xform (i.e Form rendering time, control value change time, dynamic control value change) where comparatively better when compared with same deployed in Web-logic Application Server. The logic we used to integrate the Orbeon framework with our J2EE framework is described below, 1) We store the view.xml in our database (The actual Xform which needs to be rendered). 2) We retrieve the same from the DB and inject in the request attribute as follows,

request.setAttribute(OPS_XFORMS_RENDERER_DOCUMENT_ATTRIBUTE_NAME,
            formTemplate.getTemplateContent());
getOPSDispatcher("/xforms-renderer").forward(request, response);

The above mentioned same logic we implemented both in Tomacat and Web sphere Appl开发者_高级运维ication server which seems to provide better performance than Web-logic Application Server. We found in Orbeon resource that if we edit the WEB-INF/weblogic.xml, and add the following elements:

<wl-dispatch-policy>OrbeonWorkManager</wl-dispatch-policy>

<work-manager>
 <name>OrbeonWorkManager</name>
 <max-threads-constraint>
   <name>MaxThreadsConstraint</name>
   <count>4</count>
 </max-threads-constraint>
</work-manager>

will improve the performance. Will it be useful in our situation.Kindly advise us on the above and provide us any useful recommendation which would solve our performance overhead in Web-logic Application Server.

It looks to me like this question has too many moving parts for us to be able to help you much here. I would recommend you use a good profiler, such as YourKit, to profile the same operation under WebLogic and Tomcat. You can then compare the data you have collected with each application server, and see where the difference is.

This being said, MaxThreadsConstraint should only help if you are doing loading testing. I would be surprised if this has an effect when you are sending requests to the application server one request a a time, and I would recommend you start testing that first.