Re: Memory Management using Tomcat

From: Michael Gentry (mgentr..asslight.net)
Date: Thu Sep 17 2009 - 14:27:31 EDT

  • Next message: Joe Baldwin: "Re: Memory Management using Tomcat"

    What is the size of your object cache? Look under the DataDomain. If
    it is a large number, try lowering it.

    On Thu, Sep 17, 2009 at 2:18 PM, Joe Baldwin <jfbaldwi..arthlink.net> wrote:
    > Michael,
    >
    >> With a paginated query, Cayenne fetches all of the PKs in (500-5000), but
    >> then only fetches one page of data objects (say 10, using the PKs it fetched
    >> previously) as you are looking at them, which will be more efficient for
    >> large sets where you don't use all of the data at one time.
    >
    > Yes this is a really good idea. �I have been using it for the past few
    > months now. �However, I was also using caching (which your docs say
    > interferes with BaseContext "weak reference" memory management).
    >
    > My initial plan was to cache the products that are simply being looked at by
    > customers. �However, I thought that might be a problem if as customers look
    > different products the cache will simply grow until it runs out of memory.
    > �So I am not sure if this is a good idea anymore. �Is this cache ever
    > released after a period of time?
    >
    > Second, I am investigating a comment by the Webhost tech support, who said:
    > "watch out for singletons". �Well the only thing that might be a problem
    > that I have done is to implement a Factory class, which is essentially a set
    > of class methods that I have written to accomplish to most repeated fetches.
    > �Would these fetches using static methods (I use only local variables in
    > these static methods) cause any problems with BaseContext memory managment?
    >
    > So, if these are not the problems then I guess all I can do is increase the
    > Xms.
    >
    > Thanks,
    > Joe
    >
    >
    >
    >
    >
    >
    >
    >
    >> If you are fetching 500-5000 products at a time, I'd seriously
    >> consider using pagination since it is unlikely they will look at
    >> 500-5000 products at a time. �On your SelectQuery object, do a
    >> setPageSize(10) -- or some other reasonable number (how ever many
    >> products you show on one page). �This will reduce the memory
    >> footprint. �See:
    >>
    >> http://cayenne.apache.org/doc/paginated-queries.html
    >>
    >> With a paginated query, Cayenne fetches all of the PKs in (500-5000),
    >> but then only fetches one page of data objects (say 10, using the PKs
    >> it fetched previously) as you are looking at them, which will be more
    >> efficient for large sets where you don't use all of the data at one
    >> time.
    >>
    >> As for one context/application, this is not what the thread context
    >> (which you are using) does. �The Cayenne filter creates or restores a
    >> session-based context that is kept around for that user for the life
    >> of the session. �For some applications this makes perfect sense. �You
    >> might want to keep their shopping cart objects around from
    >> request-to-request, for example. �For a catalog type application,
    >> though, I personally would probably use a brand-new context in each
    >> request for fetching catalog data, letting it go at the end of the
    >> request. �This will allow those contexts and data objects to be
    >> garbage collected much sooner. �When needing to copy something from
    >> the temporary catalog context to the user's session context (because
    >> Cayenne needs related objects in the same context), you need to use
    >> localObject():
    >>
    >> http://cayenne.apache.org/doc/moving-objects-between-contexts.html
    >>
    >> I know that was long-winded, but I hope it gave you some ideas.
    >>
    >> Also, you said, "I do not want to do this if this is not your normal
    >> procedure." �There isn't really a normal procedure. �Each application
    >> has requirements that drive how you approach it. �In one application I
    >> kept 10,000+ records in an application-level object that was shared by
    >> all sessions. �These records were read-mostly and expensive to read in
    >> (required several minutes due to the number of joins) and I cached
    >> them and controlled access to them. �This approach made sense -- for
    >> that application.
    >>
    >> mrg
    >>
    >> PS. Add the paginated queries first and see how much that buys you.
    >> That should be easy to do. �Changing the way you are using the context
    >> will be much more time consuming.
    >
    >



    This archive was generated by hypermail 2.0.0 : Thu Sep 17 2009 - 14:28:04 EDT