threading in BEA weblogic5.1


Performance and scalability: threading in BEA weblogic5.1

  1. threading in BEA weblogic5.1 (1 messages)

       I have a situation here. We are developing a search application. As per the specifications, the user enters a criteria like part number, manufacturer code etc. The application displays 250 results (thats the max limit), 25 per each page. The current application takes 600 milliseconds to retrieve 250 results to the front end with 500 users. We are using BEA weblogic5.1 application server.
    We are using a DAO(JDBC) to retrieve the results. The results are set in the session as 250 value objects.
    Users want the search to be faster.
    We found that instantiating the 250 objects is the bottleneck. So, this is what we are trying to do: When the trader enters the criteria and hits the search button, the servlet starts a thread. This thread retrieves 25 records, instantitates 25 value objects and starts a new thread. The 25 records are displayed to the user, meanwhile the second thread searches the remaining 225 results, instantiates 225 value object and adds them to the session.
    Do you see anything wrong in this approach?
  2. threading in BEA weblogic5.1[ Go to top ]

    Generally not a good idea to spawn threads inside the servlet container. The container is trying to manage resources for you, but it can't manage threads you start since it doesn't know about them.

    What happens if the user closes his browser, or hits stop. Your threads will merrily keep going right?

    What is the users problem with .6 of a second for 250 results? I am suprised they even perceive that. Might be the rendering of the results that is taking the time. A user's request for "more speed" almost always relates to the UI more than anything else! :)

    I would not spawn threads inside the servlet engine, certainly not one per search request. It's gonna get a bit chaotic in there!

    My suggestion is to look at caching the overall results. Assuming they are read only, then once they are instantiated they can be pooled. Then, when a result comes back from the DB, use one or more of the columns to key into the pool so that you simply "SELECT" the object, not instantiate it. If the user does modify it, it will be later, at which point you can clone the one object they do want to play with.

    Make sense?