General J2EE: Suggestions needed on Performance issues.

  1. Suggestions needed on Performance issues. (2 messages)

             We have a web-based intranet application and using Struts Architecture. Here are the scenarios that we are debating to choose from. I need a suggestion from experts to go with which one from the performance point of view:

    In one of our module in the application we are design 6 Tabs. There are minimum of 8 fields in a tab to maximum of 20 fields in a Tab. We are talking about 80-90 fields all together in 6 tabs. The information may increase in near future. We are using weblogic 7.0/sp2 with cluster environment with a session replication.

    Note: We are around 20,000-40,000 user bases.

    Scenario 1: Send the entire 6 tabs information to the server in one request.

    Advantages: User doesn't have to save the information (request to the server) while he navigates between the Tabs.

    Disadvantages: All the information will be in one form Object and transferring a big object across the network and needs to keep track for his navigation in the session.

    Scenario 2: Send a request with single tab information at a time.

    Advantages: The request will be a light and no need to worry about network traffic. Every thing will be request base no need to worry about the session.

    Disadvantages: Frequent requests to be made for each tab and increases the user interaction for saving the information for each tab.

  2. Hi Mandeep,

    Could the behaviour be somewhat adaptive? In so far as you keep a big old cache on in your servlet container, and do lookups in that. Then based on the aggregate user request, your application observes all user behaviour and decides what needs fectching from the server and the best way to go an get it. If most of your users are flicking through the data quickly, then get the lot (or whatever you think is best), if they're reading each page carefully, then perhaps downgrade the requests for that data to per request. (I'm talking about what you get from your server, not what you deliver over http)

  3. Hi,

    I think you should go for the second approach. My point of view is:
    Do not chase performance by sacrificing maintainability. The first approach will be harder to implement and it will require more client code.
    Do the simpler thing ! There will be a lot of options to increase the performance later (when you'll have well desinged and simpler GUI :-)

    ... just my 2 cents