Performance Enhancing a J2EE application

Thread view:

James - 29 May 2004 15:53 GMT

Hi,

I have been tasked with making some changes to an existing J2EE
application.
The changes I am making are business logic related and the deadline
(as always :-) is tight so I don't have a lot of leeway but I have
noticed the application appears quite slow at the moment.

I am hoping to find a couple of 'quick-win' performance gains and
sneak them in while I am at it.

THe application is a reporting system and is implemented using JSPs
speaking through a stateful session bean to several entity beans which
retrieve the data from custom built Oracle views, basically mapping
the data for each report. There are maybe 15 different entity beans in
the system in total.

Some of the reports have 1000's of lines of data but in these cases
the ejbLoad just returns a Vector of LineItem objects as plain old
java objects so there is not an entity bean created for every row.

I have a few ideas but am unsure if they will work.

1) I am thinking that the one big stateful session bean in the middle
may be a bit of a bottleneck. I could move the state management into
the HttpSession and use multiple stateless beans to manage the use
cases. But then again I am thinking the container should be pooling
the SF bean instances anyway so maybe it's OK as is??

2) I am seriously thinking of ripping out the entity beans altogether
and replacing them with some form of straight JDBC/DAO/alternate
non-EJB framework, maybe Hibernate..
Another possibility is to turn on 'read-only' optimisations as the
data cannot be updated through the J2EE side. There is an aspiration
to eventually enable updates so that may be an argument for leaving
the EJBs in place there.

3) Also it seems that the JSPs retrieve each property from the entity
beans in separate method calls. I am thinking it should be quicker to
have one object come across the network and have the JSPs get the
properties from that rather than traversing the RMI etc. each time..

4) Frames are also used in the HTML front-end which I presume doesn't
help speed things up either..

Anyway I was wondering if anyone has come across similar issues before
or had aby thoughts on above.. even a link to a couple of patterns
sites would be good if no direct comments..

Thanks,

Jim

Reply to this Message

John C. Bollinger - 01 Jun 2004 16:05 GMT

> Hi,
>
[quoted text clipped - 6 lines]
> I am hoping to find a couple of 'quick-win' performance gains and
> sneak them in while I am at it.

Clearly, you should work first on your actual assigned tasks. In fact,
you would do well to discuss your optimization plans with your
supervisor before modifying a single line of code toward that end, as
there may be specific reasons for any or all of the implementation
details you might be inclined to change, and there may be an
optimization project going on elsewhere or waiting in the wings. Plus,
if you do end up successfully inserting some optimization then you want
to get credit for it.

As for where to find performance gains, you _must_ profile the
application to have a reasonable chance of success in a short time
frame. There is a variety of Java profilers available, both free and
commercial, with a wide variety of capability.

> THe application is a reporting system and is implemented using JSPs
> speaking through a stateful session bean to several entity beans which
[quoted text clipped - 7 lines]
>
> I have a few ideas but am unsure if they will work.

> 1) I am thinking that the one big stateful session bean in the middle
> may be a bit of a bottleneck. I could move the state management into
> the HttpSession and use multiple stateless beans to manage the use
> cases. But then again I am thinking the container should be pooling
> the SF bean instances anyway so maybe it's OK as is??

Typically the container would maintain multiple distinct instances of
the session bean -- at minimum one per active session. Stateful beans
therefore do not scale as well as stateless ones, but unless the
application server is short on memory (and hence using a lot of VM or
doing a lot of GC) the stateful / stateless distinction is not likely to
be a performance issue. Again, however, you need to profile to really
find out.

> 2) I am seriously thinking of ripping out the entity beans altogether
> and replacing them with some form of straight JDBC/DAO/alternate
> non-EJB framework, maybe Hibernate..

I thought you were on a tight schedule. This is likely to be a fairly
large chunk of work. It is one of the more likely areas to be a
performance win, but you need to profile. Also, when you profile be
sure to analyze the DB performance: sometimes query optimization can be
a tremendous win.

> Another possibility is to turn on 'read-only' optimisations as the
> data cannot be updated through the J2EE side. There is an aspiration
> to eventually enable updates so that may be an argument for leaving
> the EJBs in place there.

If you dump the entity beans then you should still put the data access
framework behind a session bean and make sure to use XA-aware
connections. That gives you the benefits of J2EE transactions without
the entity beans. You very likely want that, especially if the
application ever will update any of the data.

> 3) Also it seems that the JSPs retrieve each property from the entity
> beans in separate method calls. I am thinking it should be quicker to
> have one object come across the network and have the JSPs get the
> properties from that rather than traversing the RMI etc. each time..

So you are suggesting creating and using a collection of value objects?
That's often a win performance-wise. But it might or might not give
the application a noticeable speedup if there is a bigger problem elsewhere.

Another alternative might be to use local EJB interfaces instead of
remote ones. That way you take RMI out of the picture altogether, at
the cost of some limitations to your possible deployment scenarios.
Beware, however, as this fundamentally changes the argument-passing and
return value semantics (you get standard Java semantics instead of
passing copies around).

> 4) Frames are also used in the HTML front-end which I presume doesn't
> help speed things up either..

It is unlikely that this is the cause of a significant speed reduction,
although it is possible that it contributes to a _perceived_ speed
reduction, depending on the browser used. The same is true of the HTML
output in general, which conceivably might be restructured to improve
client-side performance. You really, truly need to know where the
performance problems are in advance before speculatively modifying this
sort of thing.

John Bollinger
jobollin@indiana.edu

Reply to this Message

Performance Enhancing a J2EE application

Free Magazines