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 for high volume
screens that are not updated frequently, and in many cases we would want
to cache only parts of high level screens, like the product information
on the product detail page, but not the mini cart or other sub-screens
on the sides that are user-specific.
That is exactly what we would like to implement.
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 convention (but it would
result in long cache names to have the location and screen name put
together to make it unique). With this and the caching infrastructure in
OFBiz we could have size (number of elements) limits, timeouts, soft
references, etc to help manage the caches.
I'd like to use a complex/specialized key (a custom class with a
Comparator) composed by:
* screen name and screen location
* (a subset of) input parameters map (input context)
Then I'd like to implement some utils method that allow to clear all the
cache entries associated to a given screen name and screen location.
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 and such, which
often takes up BY FAR the majority of the data preparation time.
That is a good point.
One doubt I have, if we cache html output, is how to handle links with
session id information in them (for example when cookies are
disabled)... this would make the cache useless.
This sort of tool could be really nice but very complex if it had an
auto-clear mechanism like that of the entity engine, but for this sort
of things it would be REALLY hard to have some sort of change
notification mechanism that is used for as much of what goes into screen
contexts as possible. Anyway, my point is that it's probably not
feasible to do this and we shouldn't worry about it initially. The tool
would have value with proper use even without that.
Yep, initially I would prefer to skip this part and just implement
manual clearing of cache entries (by screen name) and expiring cache
based on ttl set in the screen definition.
One thing about this, BTW: for screens that use all cached data
retrieval it would be interesting to time the difference in execution
because as they are now, these things run pretty fast. There would
certainly be a difference, but I'm wondering how much of an impact it
might have. Still, for ecommerce and content sites that are going
through a million pages an hour, this sort of feature could be the
difference between using OFBiz and some other technology entirely.
Yes, I would be curious to see the difference too, but I guess it is not
so easy to test.
Thanks for your valuable feedback,
Jacopo
-David
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 static screens (for
example a category or product detail screen in the ecommerce); this
could be done by implementing screen widget output caching that
prevents the screen widget actions (and possibly ftl) from running
Draft/proposal for implementation:
a) add new attributes in the screen definition for cache settings
(e.g. cache="true|false" etc...)
b) the cache key can be derived from the screen name and the
"parameters" map (the output UtilHttp.getCombinedMap(...)) that
represents the input context for screens
c) associated to the cache key we will cache the final output of the
screen (html code or xsl-fo code...)
d) if the cache is enabled for a given screen, the input "parameters"
map is used as a key for the cache system, if no value is found, then
the screen (actions + froms + ftl templates) is run as usual and the
output is rendered and stored in the cache (with key screen name +
"parameters"); if the value is found, then the output is retrieved
from memory and sent to the user (no actions and ftl are executed)
A different option would be that of storing the output context in the
cache and serve it to the ftl (instead of storing the output
html/xsl-fo).
I'd love to get your feedback about this, ideas/concerns,
Jacopo
