Hi, I made the defaults 0 so as not to significantly alter the behavior in the default sample-container. These values should absolutely be changed in production systems for improved performance based on the number of distinct gadgets served etc.
-Louis On Mon, Jul 7, 2008 at 2:57 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > On Mon, Jul 7, 2008 at 2:48 PM, Marijn Speelman <[EMAIL PROTECTED]> wrote: > >> On 7-7-2008 21:25, Kevin Brown wrote: >> >>> On Mon, Jul 7, 2008 at 10:49 AM, Marijn Speelman <[EMAIL PROTECTED]> >>> wrote: >>> >>>> Is it true that this effectively turns these two caches off, because >>>> whenever an element is added to the cache, it will be thrown out >>>> immediately >>>> because the size exceeds the capacity? >>>> In other words: is this the way to choose between http response caching >>>> OR >>>> just the gadget/messagebundle caching? >>>> >>> >>> You should use both. The manifest files (gadget spec + message bundles) >>> should be cached in memory because the cost of parsing the xml is fairly >>> significant (in profiling, it's by far the most expensive operation in >>> the >>> stack, even beating out link rewriting). The HTTP cache is more general >>> purpose, and in a production environment you would always want to use a >>> distributed cache such as memcache. >>> >> >> Thank you for clarifying that. So, just to be sure, by default the >> (parsed) manifest files are NOT cached as their cache capacity is set to 0 >> in the configuration, but it's advised to do change this number so they will >> be? >> > > The defaults should probably actually be changed. Louis added this, so > maybe he had a good reason for defaulting to zero. >
