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
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.
Ouch, that's a good one...
Actually, in order for this to work the cached screen couldn't have
anything request or session specific in it. This is a trick because
the request and session objects will typically be in the context and
may be used in the rendering of the screen. We'd probably have to
remove those from the copy of the context that is used for the unique
identifier creation.
Yes, we will have to remove some stuff (or just ignore it in the custom
Comparator), for example the nowTimestamp, etc...
But the decision will be difficult for some variables: for example,
should we ignore the userLogin object? If we consider it then the screen
cache will be only useful for anonymous users; if we ignore it then we
could miss important information (prices specific for a customer etc...)
That could get a little messy. For this particular issue we can
probably make sure the jsessionid is never added, though that may
cause problems transitioning from/to HTTP to/from HTTPS in some browsers.
Yeah, that's a rough one... no really good solution is hitting me for
that. What is hitting me is that we're likely to run into other things
like that... :(
That is exactly what is worring me...
Jacopo
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 every page
request requires an xml file read, element parsing, converting parsed elements into a collection of
java classes, and some validation. With a hypothetical million-hit-per-day site, all of those steps
are repeated millions of times per day. Why not do those steps once, and then cache the result?
-Adrian
