On Wed, Jun 4, 2008 at 8:37 AM, Marijn Speelman <[EMAIL PROTECTED]> wrote:
> Hi, > > I've got a couple of questions related to gadget caching in Shindig (Java). > > - Caching of rendered gadgets > I've been looking through the code and as far as I can see only the > Gadget specs (external XML files) are cached, in memory. Is this > observation correct? If so, wouldn't it make sense, performance wise, to > cache the rendered gadgets as well? I have no data on the performance of > the Gadget rendering (XML -> HTML+JS), but it would probably be best to > cache as close to the presentation of the gadget as possible. Not really. The cost of transforming gadget -> output is fairly small, and things that require expensive operations (like rewriting) are indeed cached. Caching the final output is not good because things get injected into it (such as preloads, configuration, or skinning values) differently depending on where it runs. You also have user input being substituted into the output, which makes the cache only good per user. The cost of processing substitutions is very cheap (a single pass over the input), whereas attempting to cache the output for every user / locale combination would require either obscene amounts of memory or would render the cache itself useless (too quickly polluted) XML files aren't the only things cached -- all http requests can be cached as well (this includes, but is not limited to, both Preload elements and gadgets.io.makeRequest). > > - Distributed cache > We're going to run Shindig on multiple (10+) servers to share the load. > At the moment Shindig only caches per instance on each server, so for > these kind of distributed setups it would be nice to have a distributed > caching system buldin. I'm planning to implement a Memcached backend for > this (because we already have a large memcached pool), but I was > wondering if anyone else is already doing the same or working on > something similar. I'm also curious about the progress on these two > tickets: > * https://issues.apache.org/jira/browse/SHINDIG-173 > * https://issues.apache.org/jira/browse/SHINDIG-279 (although this is > related to an ehcache implementation, it could be useful). There hasn't been any real progress on either because caching needs have proven a bit too diverse to settle on a single solution. Right now you can trivially use a shared cache by binding your own HttpCache and/or GadgetSpecFactory (I recommend just using the distributed caching on HttpCache -- you'll want gadget specs to be in memory for optimal performance). > > > Thanks in advance, > > Marijn Speelman > >
