Needs to improve the performance of the application

I have been working on an application configured completely on Core Java, Servlets and JSP's using RAD 7 as IDE, i need to improve the performance of the application, after doing analysis on the existing flow, our senior team came up with some solutions to improve its performance, please find below the listed options and suggest me the ways i can work them out.

1. There are unnecessarily used session variables and attributes once the work with that variables is done, i need to trace them out and pull them out from the session, so as to reduce the session data and improve the performance as a whole.

2. There are so many reports generated using our application, for each of these reports there is search criterion option provided, it acts as filter for reports, some of search criterion is very huge like, entire users list their locations are fetched and stored in the session, instead of storing them in the session we need to hit the server and get the list on every time, which decreases the data in the session.

3. The steps to make all the existing beans serializable.

4. In one of the feature in the application, we are generating the information using sessions, we need to move this session stuff to a bean and whenever required need to load the data, what are the ways for moving the logic from sessions to java beans, what are the things needs to implemented.

Are you sure the performance issues are caused by session memory issues?

Kiran Chintha

Greenhorn

Posts: 15

posted 8 years ago

Yes David, so much analysis has done on the same, this application is being handled since long time about past three years and came up with the solution to recover the session related issues which are mainly causing the performance related problems with the application. Please give me the ways i can handle it out.

1. There are unnecessarily used session variables and attributes once the work with that variables is done, i need to trace them out and pull them out from the session, so as to reduce the session data and improve the performance as a whole

This is will be a fairly huge architectural change to your applicaiton surely? Do you have a dependable, accross the board way of identifying unused session data? The common approach to cached data is to use an algorithm like LRU or whatever is most suited and drop data from the cache once a certain threshold has been reached, so I suppose you could implement fomr SessionListener that checks the current user's session and ditched something if the session is getting too big. Sounds fairly high risk though. If this were a fairly mature application I'd be looking to simply make more resources available if possible, rather then writing clean up code.

2. There are so many reports generated using our application, for each of these reports there is search criterion option provided, it acts as filter for reports, some of search criterion is very huge like, entire users list their locations are fetched and stored in the session, instead of storing them in the session we need to hit the server and get the list on every time, which decreases the data in the session.

After you have fired the developer who though of this approach you could look to moving the session data to a different cache level. Do you use an ORM? It might be possible to get this data from whatever cache this uses. If a cache is inappropriate you could move the criteria back on to the query behind the report and tune the database accordingly.

3. The steps to make all the existing beans serializable.

Easy enough surely?

4. In one of the feature in the application, we are generating the information using sessions, we need to move this session stuff to a bean and whenever required need to load the data, what are the ways for moving the logic from sessions to java beans, what are the things needs to implemented.

Again, this is a pretty fundamental architectural change. Are you sure you can't work round this by chucking more resources at your application?

1. I will implement the tracking as suggested by you for the first item.
2. For second item, we are not using any ORM tool for this report generation right now, could you provide any further analysis for the same.
3. For third item, according to my understanding whatever the existing bean classes are there, all these needs to be updated as every class should implement Serializable interface, is this the only change needs or any further changes to be taken care off.
4. For fourth item, could you please guide me out, with your analysis as i am not able to clearly understand the change you are suggesting for this implementation.

Kiran Chintha wrote:4. For fourth item, could you please guide me out, with your analysis as i am not able to clearly understand the change you are suggesting for this implementation.

The suggestion is to provide more RAM, a load-balancer, etc.

You're being asked to make a fundamental change to your application: it might be cheaper to add hardware rather than go through the process of regression-testing your changes, particularly if there's no automated testing process already in place.

1. I will implement the tracking as suggested by you for the first item.

I'm not sure I'd recommend this unless your applciation were so badly written the performance issues are pretty much terminal or the application is at a fairly early stage in its development. It might not sound too nice a solution but giving your application more resources might be more prudent.

2. For second item, we are not using any ORM tool for this report generation right now, could you provide any further analysis for the same.

The features of an ORM I was suggesting was simply a different place to cache data. You can look at any ORM (if your applicaiton is backed by a database it is certainly something to keep in mind), but if its not currently in your architecture youcould just look a simple cache implementation (e.g. JCS) and move shared data from the session to the cache.

4. For fourth item, could you please guide me out, with your analysis as i am not able to clearly understand the change you are suggesting for this implementation.

Giving your application more resources is much easier to do than swap your applicaiton from once that uses cached data heavily enough to cause a performance problem in the first place to one that is stateless. Have you tried using a 64 bit JVM for example and increasing the heap? Or deploying this in a cluster?

All this depends really on how big and how mature your application is. Trying to retrofit such a fundamentally different approach might signal its easier to throw the application away and start again. You have to weigh up the likely impact (in bugs and maintenance) of a significant code rewrite against the cost of buying a few more servers and using the tool JEE containers give you to scale your application.