I'm trying to narrow down where performance issues are in the response time of a web service.
One thing that comes of interest is that it seems that a Stateless Session Bean thread is removed once it completes. This causes a delay with each call to the web service. Comparing a simple servlet or local class invocation showed that without the EJB the response time was <1ms but was 10-20ms when the code was deployed as a LocalEJB (>20ms as a RemoteEJB). What I would like to happen is for JBOSS to keep a minimum number of threads active so that when an EJB instance is needed they are already instantiated. I tried setting the pooling to a MinimumSize but I have read that JBOSS ignores this parameter. In this deployment, the EJB is called through a Local interface and will most likely remain that way in production. The larger system is doing basically a lookup with some transformation (including CORBA, Database, etc.) of the data and analysis shows that this EJB invocation is the largest delay in the overall response time. The application has to be scaleable and responsive to support large volumes of batch and transactional request. In theory, this is architecting a solution to put a web service facade on Enterprise CORBA services. Does anyone have suggestions or tips on what to do to increase the throughput and/or configure JBOSS for this type of application? My thoughts are to either find a way to configure/customize JBOSS to maintain these threads across invocations (pooling of the stateless session beans) or to re-architect the solution to use a different type of bean (or different method for deploying the logic). The stateless session bean is part of the pattern for deploying a web service so changing that would affect many developers and systems and I would like to minimize change if possible. Any help would be much appreciated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4013770#4013770 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4013770 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
