servlet context/Action class - performance question.

[sg...@sears.com]

The requirement is to display a page with some categories just like the
yahoo homepage. The link of each main category will have to show the
subcategories of that category in a similar page. The level of this tree
goes one more level inside. All this information is built ofcourse by
retrieving from the database.

First thought was to build the relevant section of the category/subcategory
tree based on the request parameters. Since these pages are going to be the
"most viewed" (and does not change based on the user), I thought it would
be better for performance if the whole tree is created in a startup servlet
and put in servlet context instead of creating a part of it in the Action
class and setting it into the HttpServletRequest. This would mean that I
wont have to hit the database for every user request. I will just have to
get the relevant part of the category tree from the (big) object in servlet
context based on a key lookup on the TreeMap.

The pages load surely very fast, ~but~ I am wary of such a big object in
memory and its effect on the performance once it goes into production.

To give a rough idea about the size of this tree: 1 main category (TreeMap)
has about 12 subcategories (TreeMaps again). Each of the subcategories has
about 10 child categories. Each child category is a ArrayList of strings.
So its a TreeMap of TreeMaps of ArrayLists.

Did anybody face similar design choice and had to choose against a setting
so much information in the servlet context? Any input is greatly
appreciated!

I apologize for the subject being a little off-topic.

Thanks,
-Shyam Gouri


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: servlet context/Action class - performance question.

[Bharat Nagwani <bh...@cisco.com>]

We store much more information that in our
application context and dont have any performance issues.
We store all our master data (static) on startup. The
performance is enhanced.

Again it depends on how much
data you have and how much it is supposed to grow over time.
That you should consider.

At 01:01 PM 6/3/2002 -0500, you wrote:
>The requirement is to display a page with some categories just like the
>yahoo homepage. The link of each main category will have to show the
>subcategories of that category in a similar page. The level of this tree
>goes one more level inside. All this information is built ofcourse by
>retrieving from the database.
>
>First thought was to build the relevant section of the category/subcategory
>tree based on the request parameters. Since these pages are going to be the
>"most viewed" (and does not change based on the user), I thought it would
>be better for performance if the whole tree is created in a startup servlet
>and put in servlet context instead of creating a part of it in the Action
>class and setting it into the HttpServletRequest. This would mean that I
>wont have to hit the database for every user request. I will just have to
>get the relevant part of the category tree from the (big) object in servlet
>context based on a key lookup on the TreeMap.
>
>The pages load surely very fast, ~but~ I am wary of such a big object in
>memory and its effect on the performance once it goes into production.
>
>To give a rough idea about the size of this tree: 1 main category (TreeMap)
>has about 12 subcategories (TreeMaps again). Each of the subcategories has
>about 10 child categories. Each child category is a ArrayList of strings.
>So its a TreeMap of TreeMaps of ArrayLists.
>
>Did anybody face similar design choice and had to choose against a setting
>so much information in the servlet context? Any input is greatly
>appreciated!
>
>I apologize for the subject being a little off-topic.
>
>Thanks,
>-Shyam Gouri
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>