Caching or not is also a decision that you sometimes want to change after you see your application used in anger for a while. I like to provide a getter method on some application scoped bean that returns things like this, so I can change my decision to implement caching (or not), for any given set of data, without impacting the rest of the application -- it just calls the getter whenever it wants that data.
Craig On Tue, 15 Feb 2005 13:58:32 -0500, Soaring Eagle <[EMAIL PROTECTED]> wrote: > Without contesting the good points. I would say memory is cheap. For > an application i worked on, we had about 6 different applications > sitting on two 4 by 16 machines. The -xmx arguments of all apps put > together came up to about 10 gigs RAM and the rest was left open. i > dont think serious application owners care about money sunk on > hardware. > > Further, I agree that caching requires an overhead in terms of keeping > various clusters in synch or managing updates etc.. but clients can be > kept transparent of all this. there may be a period of a few 100 > milliseconds to upto a couple of seconds when clients may get dirty > reads if the cache design allows it - but that could be a small price > to pay over the general speed of cache access. > > Anyways - sorry for contributing to making this a totally non-struts topic! > > > On Tue, 15 Feb 2005 11:03:01 -0500, Bill Schneider <[EMAIL PROTECTED]> wrote: > > >> how do you manage cross container caches if you are clustered - when > > >> you are using static members on classes? How do guarantee sameness on > > >> different physical machines? We do have a few caches in our > > >> application and are facing issues due to this design or an improperly > > >> implemented version of this design. > > > > Also, be aware that caching can actually degrade application performance > > in some cases. Everything you cache takes space in the JVM heap, > > reducing what's left to process active requests. So it's possible to > > lose more cycles in GC than you saved by caching in the first place. You > > can just keep increasing -Xmx, but that can hurt you if the JVM starts > > using swap space/virtual memory for the Java heap. > > > > If you're using a clustered cache, you also have the overhead of keeping > > the caches on each JVM in sync. That adds network as well as processing > > overhead for marshalling and unmarshalling cached objects. > > > > In summary, J2EE webapp performance involves a lot of tradeoffs. Caching > > is important but has to be used judiciously to be beneficial. > > > > -- Bill > > -- > > Bill Schneider > > Chief Architect > > > > Vecna Technologies > > 5004 Lehigh Rd., Suite B > > College Park, MD 20740 > > [EMAIL PROTECTED] > > t: 301-864-7253 x1140 > > f: 301-699-3180 > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
