How to reduce network load between client and server?

Discussions

EJB design: How to reduce network load between client and server?

  1. we have a WAN system of 19.2KBps only and clients are situated all over the world. The client interfaces are in swing and we r using Sateless session bean to get the resultset from the oracle database which is on HPUnix.
    We r not able to load even those tables which has 1000 or more than 1000 records. Kindly suggest me if there be any way to reduce network traffic .

    Threaded Messages (8)

  2. You may look to use the java.util.zip package to compress the object before serializing it. You can then uncompress it in your client application.
  3. You may want to try the option of getting results on demand.
    Instead of getting the whole results as a big value object, you may want to initially get a subset of the records and later get the remaining subsets on demand.

     In your case, you might not show all the 1000 records in a single screen in the swing application. So, you can fetch only 100 records and display them. Later on when the user clicks on next button you might want to fetch the remaining 100 records and so on.

     With this apporach there will be too many hits to the server. This can be optimized by getting the optimum number of records(100 in example) under which your system performs well.

    ..Kiran
  4. cache[ Go to top ]

    I don't know if you've done this already but you could introduce a "cache object" in the client app to make sure certain information is requested only once from the server.

    This is pretty easy to implement and may save you lots of time/bw ..

    Best regards,
    Bjørn Børresen
  5. cache[ Go to top ]

    I don't know if you've done this already but you could introduce a "cache object" in the client app to make sure certain information is requested only once from the server.

    >
    > This is pretty easy to implement and may save you lots of time/bw ..
    >
    > Best regards,
    > Bjørn Børresen

    Cache is a good idea here...but you might want to tackle the issue of dirty records....Mark the cached copy of records, targetted during updates, as dirty and the next time around just fetch the "dirty" records.....
    there might be error scenarios where the updates did not succede and you can have an advanced mechanism for marking them back as "clean", but I think that you will be okay without it as well as in the worst case you will just be fetching some records.
  6. cache[ Go to top ]

    /Cache is a good idea here...but you might want to tackle the issue of dirty records....Mark the cached copy of records, targetted during updates, as dirty and the next time around just fetch the "dirty" records.....
    there might be error scenarios where the updates did not succede and you can have an advanced mechanism for marking them back as "clean", but I think that you will be okay without it as well as in the worst case you will just be fetching some records. /

    You may go backwards to this way. I mean not to mark durty records and analize then what to update but to sore on the server the last request time for a client and for a comming request return just records updated since the last-request-time. This approach supposes that all (write) actions over the data are logged in a history table and this history maybe browsed.
  7. cache[ Go to top ]


    > You may go backwards to this way. I mean not to mark durty records and >analize then what to update but to sore on the server the last request time >for a client and for a comming request return just records updated since the >last-request-time. This approach supposes that all (write) actions over the >data are logged in a history table and this history maybe browsed.

       What you are saying makes more sense Roman..Becuase that will insulate the system from the problem of different clients updating the records...I had made the mistake of not taking that into picture
  8. cache[ Go to top ]

    I guess Value List Iterator pattern addresses your problem.
  9. It might be a good idea for the systen folks to take a look at your network config too...

    and u should also analyze your app to see if its too "chatty".
    Can u cache some objects at client side (as other have suggested)Keep in mind when wouuld these objects be cached
    some objects need not be cached0 like list oc cunteries or currencies but some need frequent refresh like exchange rate- so u have to make a analytica decision as to what you can cache and what you shouldnt

    you can use some sniffer programs to see what exactly is causing the server to behave errantly
    u have also not mentioned the exact problem you are facing
    does it crash ?
    do u get Out of memory error ?
    do u get time out errors?