In rev. 559384 I've committed the first version of my work.
I'd like to get your feedback (see the commit logs for details).
David, I've implemented it following your great suggestions (I've used
the enity cache as a reference); the first tests are good even if I have
already noticed some weird
Thanks for the clarification. I learned something today. :)
Jacopo Cappellato wrote:
Adrian,
that is correct, in development mode (the default) screen widget caching
is disabled.
Jacopo
Adrian Crum wrote:
Jacopo Cappellato wrote:
Adrian,
That's why I suggested caching the wi
Adrian,
that is correct, in development mode (the default) screen widget caching
is disabled.
Jacopo
Adrian Crum wrote:
Jacopo Cappellato wrote:
Adrian,
That's why I suggested caching the widgets themselves. If the
discussion is about a site that is getting a million hits pe
Jacopo Cappellato wrote:
Adrian,
That's why I suggested caching the widgets themselves. If the
discussion is about a site that is getting a million hits per day,
then caching the widgets should offer some level of improvement.
Reading and parsing the widget xml file might seem to go fast,
Adrian,
That's why I suggested caching the widgets themselves. If the discussion
is about a site that is getting a million hits per day, then caching the
widgets should offer some level of improvement.
Reading and parsing the widget xml file might seem to go fast, but the
reality is that e
Jacopo Cappellato wrote:
If we did something like this my vote would be on caching the entire
output of the screen. If someone wanted to speed up the data
preparation chances are the most effective way to do it would be to
use the entity engine caches to help with database round trip delays
an
David,
David E Jones wrote:
Jacopo Cappellato wrote:
Also when used this would be more susceptible to stale information as
the only easy mechanism for refreshing these is a time limit. We
would probably want to make it possible to specify the cache name to
cache the screen in, or I guess we
Jacopo Cappellato wrote:
Also when used this would be more susceptible to stale information as
the only easy mechanism for refreshing these is a time limit. We would
probably want to make it possible to specify the cache name to cache
the screen in, or I guess we could just have some conventi
David,
please see my comments inline:
David E Jones wrote:
I think this is a great idea. As with any other caching tool it needs to
be used properly, and based on some of the responses there seems to be
some misunderstanding about that.
Just as with entity caches this would only be helpful
I think this is a great idea. As with any other caching tool it needs to be
used properly, and based on some of the responses there seems to be some
misunderstanding about that.
Just as with entity caches this would only be helpful for high volume screens
that are not updated frequently, and
Or, you could take the approach that the OS is responsible for caching things on a local storage
device - then go ahead and code as if you have unlimited memory.
Chris Howe wrote:
Perhaps, instead of output caching to memory, output to a "temporary"
contentId and store the output to disk or to
Perhaps, instead of output caching to memory, output to a "temporary"
contentId and store the output to disk or to xml database?
--- BJ Freeman <[EMAIL PROTECTED]> wrote:
> seems that the processing of the key would take up a lot of memory
> and
> time to process, assuming that 90% of the widgets
seems that the processing of the key would take up a lot of memory and
time to process, assuming that 90% of the widgets were cached.
Jacopo Cappellato sent the following on 7/17/2007 8:32 AM:
> Hi all,
>
> I'd like to discuss with you all about the idea of implementing screen
> widget output ca
Apply cache in services or entityes
2007/7/17, Adrian Crum <[EMAIL PROTECTED]>:
I think caching the widgets themselves might offer an improvement. I have no
opinion on the other items.
-Adrian
Jacopo Cappellato wrote:
> Hi all,
>
> I'd like to discuss with you all about the idea of implementi
I think caching the widgets themselves might offer an improvement. I have no
opinion on the other items.
-Adrian
Jacopo Cappellato wrote:
Hi all,
I'd like to discuss with you all about the idea of implementing screen
widget output caching.
Goal: minimize the db/service hits for rather stat
Hi all,
I'd like to discuss with you all about the idea of implementing screen
widget output caching.
Goal: minimize the db/service hits for rather static screens (for
example a category or product detail screen in the ecommerce); this
could be done by implementing screen widget output cachi
16 matches
Mail list logo
