Managing performanc for J2EE based GUI applications

Discussions

Performance and scalability: Managing performanc for J2EE based GUI applications

  1. Managing performanc for J2EE based GUI applications (7 messages)

    Hi All,
    We have developed a very simple Enterprise application in the utilities sector. The application uses Stateless session beans, Value objects and is web-based. The application currently in its testing phase is facing huge problems of screen response times. To this affect would apprciate any ideas by which we can improve the performance. One which comes to our mind is some kind of 'screen-caching' but then the application presents data based on the user who has logged into the system. Basically the application presents user-specific data with some parts of generic data.
    We tried using JCS but it looks like therez a lot of effort involved and might even need to change the code a lot for such a solution.
    What i am ideally looking at is that the solution sits on top of the already developed and tested application and does its job. Might sound to be a bit late in the cycle but thats what it is currently.

    Any suggestion will be really appreciated.

    -Rohit
  2. try using PerformaSure from Quest ...that might help you to find about poor response time
  3. Trying to improve performance[ Go to top ]

    Hi,
    Thanks for the response.
    But we have done all performance measurements and tuned the code as much as possible according to the recommendations. But the things is that we are now out of options and hence looking for the caching solution.

    Regards
    Rohit
  4. Trying to improve performance[ Go to top ]

    Hi Rohit,
    One which comes to our mind is some kind of 'screen-caching' but then the application presents data based on the user who has logged into the system.

    In general, we recommend caching at each level of the application, which may not come as a surprise since we provide a caching solution ;-).
    Basically the application presents user-specific data with some parts of generic data.

    Where does this data come from? And are you doing local caching of this data currently?
    But the things is that we are now out of options and hence looking for the caching solution.

    Take a look at Coherence.
    What i am ideally looking at is that the solution sits on top of the already developed and tested application and does its job. Might sound to be a bit late in the cycle but thats what it is currently.

    If you are currently doing local caching and using the collections API to do it, Coherence can plug in quickly and easily:

    import com.tangosol.net.NamedCache;

    [...]

    // create a clustered cache
    NamedCache cache = CacheFactory.getCache(sName, classloader);

    // access data in the clustered cache
    cache.put(oKey, oValue);
    [...]
    cache.get(oKey)

    // concurrent access to an object in the clustered cache
    cache.lock(oKey)
    [...]
    cache.unlock(oKey);

    Later,
    Rob Misek
    Tangosol, Inc.
    Coherence: It just works.
  5. i dont think Coherence will solve your problem. what oyu should look for is ValueListHandler. i.e if you are wanting to cache the results sets

    When an application uses enterprise beans in the business tier, it may be preferable to implement a session bean that uses the ValueListHandler. In that case, the session bean simply fronts an instance of a ValueListHandler. Thus, the session bean may be implemented as a stateful session bean to hold on to the list handler as its state, and thus may simply act as a facade
  6. Solution which fits on top[ Go to top ]

    Thanks Rob and Shahrukh,
    Shahrukh your suggestion is valid but the only problem is that as i mentioned we have competed the coding and almost throught with two phases of testing. Now turning back and modifying the code is out of testion due to the sheer amount of testing effort which will be involved.

    Rob to answer your question
    The application presents the data for the users from ORACLE DB. Basically for every user request the appserver (using Stateless Session Beans) makes a call to the DB to get the data. This data is then put in a arraylist of value objects and passed to the client browser. The browser then renders the page from the data in the collection.

    In essence for every user request we are creating the value objects and using the collection which in retrospect is a bad solution. But we have to live with it as thats all we have......

    Thanks
  7. Solution which fits on top[ Go to top ]

    if that is the case then my reommendation is to use PerformaSure ....we use as part of our on going development
    and that might be able to tell you what is a bad java code or JDBC call...I hv been using this performasure tool for the last 9 months and it does give us some benefits
  8. ... The application currently in its testing phase is facing huge problems of screen response times. To this affect would apprciate any ideas by which we can improve the performance. ....What i am ideally looking at is that the solution sits on top of the already developed and tested application and does its job. Might sound to be a bit late in the cycle but thats what it is currently.

    Rohit, you only have two choices:

    1) Spend more time, trying to find out where is the bottlenecks that are below the performance problem, and fix the code (or the SQL sentences) that are facing bad response times.

    2) Deploy the application and the database on stronger machines (more CPU and more memory).

    Rohit, face it: if you have performance problems in your application, you must diagnose which SQL sentences are having worse response times, and fix them. When you finish with the SQL sentences, you must fix all the java code with poor response time (you are going to need to use some tool such as Quest PerformaSure).

    If you cannot modify the SQL and the source code, then the only thing you can do to improve the response time is to buy more hardware. It sounds very hard, but it's the reality. Of course, when an application has a poor design, not always more hardware is the way to go, so I recommend to fix the code.


    Jose Ramon Huerga
    http://www.terra.es/personal/jrhuerga