You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Jim Pinkham <pi...@gmail.com> on 2009/04/09 18:29:39 UTC
Re: Can client cache pages effectively?
A quick follow up in case anyone else was curious about how this is going:
I ended up using ehcache page cache filter for a simple page that just
displays 'current' items (calendar view of events) based on a db query. No
forms (state) on this page so it works pretty well. In my DAO that does
updates, I clear the cache. Very simple, works great. (Only catch I ran
into is that my menus change when I have a session and I'm logged in as
super-user, so I have to make sure I don't let that version of the page be
cached - I do that by adding 'super' page parameter so URL is different
and filter is set to only cache the 'normal' version.
So, that still leaves me with my main catalog page, which is primarily a
similar list of items, but it also has some active content (in particular, a
search form).
So my bright idea (tm) (i.e. I'd love to hear critiques before I get too
far along with it) is the following:
Make a new page for just the data grid, with page parameters including the
search string and last-modified date (and super-user login because I get
some edit links and such with that). Mount it and ehcache it, and override
setHeader so it becomes client cache-able. Then, my outer catalog page
with the search form on it just uses an IFrame to display the grid data
(easy to keep track of last-modified globally). Same clear method in DAO
dumps the cache whenever a change is made.
Also, I'd want to make a robot no-follow thing to avoid google trap on that
page. Could this actually be a legitimate use of otherwise dodgy IFRAME ?
Sound like a good plan?
Thanks,
-- Jim.
On Fri, Mar 27, 2009 at 1:56 PM, Jim Pinkham <pi...@gmail.com> wrote:
> Jeremy,
>
> Thanks for your thoughtful reply - Scenario is exactly right.
> I played around with page headers to make the whole page cacheable, but ran
> into several problems - I have a search form, and there's an 'admin' login
> that enables edit links. So it's really a stateful page, but I want to
> speed up the most common state.
>
> The bulk of the content is from an AjaxFallbackDefaultDataTable with
> sortable columns. I re-sorted a column with the Ajax Debug window open to
> measure it's data size - about 225000 chars. My database search takes
> 64ms. Overall client repaint time is about 2 sec with browser on
> localhost. I haven't found the right hook to measure total wicket response
> time yet, but it appears pretty quick - so that's why I thougth it made
> sense to focus on client caching.
>
> Before I give up entirely on this idea, I'm wondering if it might make
> sense to make the grid a public Resource, which I'm hoping the browser would
> treat like an image. I can afford a separate db query to just get my
> max(lastModified), which might let me save the time to generate HTML, which
> looks as though it could be my bottleneck. If this way is too hard, I'll
> give up, but it sounds do-able - what do you think?
> Thanks,
> -- Jim.
>
>
> On Thu, Mar 26, 2009 at 6:30 PM, Jeremy Thomerson <
> jeremy@wickettraining.com> wrote:
>
>> How is this going to help you? Scenario as I understand it:
>>
>>
>> 1. User requests homepage - pulls from site - with your etag in it
>> 2. User requests homepage again - calls site - your server does all of
>> the loading of data - then you calculate / set etag
>> 3. Browser now knows that it is the same as before and does not have to
>> pull the HTML down
>>
>> The user saves what is likely a very short time in the overall scheme of
>> things - downloading the HTML.
>> The user still has to sit through the process of you loading the data from
>> the search / DB / etc. and generating HTML
>> Your server saves no load - but a little bandwidth.
>>
>> I'd look at caching before it even gets to your server. Otherwise your
>> user
>> will likely not see much benefit unless you are sending multiple MB of
>> data
>> back. Sounds like premature optimization to me.
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>> On Thu, Mar 26, 2009 at 5:26 PM, Jim Pinkham <pi...@gmail.com> wrote:
>>
>> > Thanks Jerry; I think that applies only to static pages.
>> >
>> > My next idea is to try overridding WebPage.setHeaders and just set the
>> >
>> > response.setHeader("Cache-Control", "max-age=3600, must-revalidate");
>> >
>> > response.setHeader("ETag", "1"); // I'll use a checksum on the data
>> coming
>> > back from my search (Even better would be a checksum on the rendered
>> page
>> > data - any idea how to do that?)
>> > Initial test (above) seems promising...
>> >
>> > Thanks,
>> > -- Jim.
>> >
>> > On Thu, Mar 26, 2009 at 3:22 PM, Jeremy Thomerson <
>> > jeremy@wickettraining.com
>> > > wrote:
>> >
>> > > Have you looked at a standard HTTP caching proxy like
>> > > http://www.squid-cache.org/ ?
>> > >
>> > >
>> > > --
>> > > Jeremy Thomerson
>> > > http://www.wickettraining.com
>> > >
>> > >
>> > >
>> > > On Thu, Mar 26, 2009 at 2:02 PM, Jim Pinkham <pi...@gmail.com>
>> wrote:
>> > >
>> > > > Changing my search query to this got some better hits:
>> > > > http://lmgtfy.com/?q=cacheability
>> > > > So, allow me to refine my question based on that - has anyone tried
>> > some
>> > > of
>> > > > these approaches (see first result from above) to generrate and dump
>> > > > content
>> > > > to a static file (renamed if it chages) and having the wicket home
>> page
>> > > be
>> > > > a
>> > > > redirect to that file, or something like that?
>> > > >
>> > > > Thanks,
>> > > > -- Jim.
>> > > > On Thu, Mar 26, 2009 at 12:53 PM, Jim Pinkham <pi...@gmail.com>
>> > > wrote:
>> > > >
>> > > > > I've found a few posts about how to mark dynamic pages so they
>> won't
>> > be
>> > > > > cached.
>> > > > >
>> > > > > I've got a different situation that I think is fairly common - the
>> > > 'home'
>> > > > > page of my app is effectively a (cheesr-like) catalog of items
>> that
>> > > > changes
>> > > > > infrequently. Users didn't like paging, so it's about 300 items
>> in
>> > a
>> > > > > simple scrollable page. Once a user views it, they often drill
>> down
>> > > into
>> > > > an
>> > > > > item, then use the back button (or sometimes the Home link) to
>> > > re-display
>> > > > > it.
>> > > > >
>> > > > > The db query is actually pretty fast; I think the bottleneck seems
>> to
>> > > be
>> > > > > fetching the HTML.
>> > > > >
>> > > > > My question is, can I use some kind of header caching hint with a
>> > > version
>> > > > > number so that once the content is identified as being the same as
>> a
>> > > > > previously fetched page, the user's browser will repaint it from a
>> > > local
>> > > > > cache? (I know this is typically done with images, but I was
>> > wondering
>> > > > if
>> > > > > this would make sense to do also do with content that technically
>> > > > 'dynamic'
>> > > > > but actually is 'fairly static' ? (I say version number rather
>> than
>> > > > time
>> > > > > to expire so that in case I add/change an item I can increment the
>> > > > catalog
>> > > > > version)
>> > > > >
>> > > > > Thanks,
>> > > > > -- Jim
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Can client cache pages effectively?
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Still sounds like you're jumping through hoops to force this HTML caching to
fit - possibly opening up security vulnerabilities by exposing a user's role
in the URL - which should only be in the session. I maintain that you'd be
better off caching the data - that's the expensive part anyway.
But it's your app and that's my two cents. :)
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Apr 9, 2009 at 11:29 AM, Jim Pinkham <pi...@gmail.com> wrote:
> A quick follow up in case anyone else was curious about how this is going:
>
> I ended up using ehcache page cache filter for a simple page that just
> displays 'current' items (calendar view of events) based on a db query. No
> forms (state) on this page so it works pretty well. In my DAO that does
> updates, I clear the cache. Very simple, works great. (Only catch I ran
> into is that my menus change when I have a session and I'm logged in as
> super-user, so I have to make sure I don't let that version of the page be
> cached - I do that by adding 'super' page parameter so URL is different
> and filter is set to only cache the 'normal' version.
>
> So, that still leaves me with my main catalog page, which is primarily a
> similar list of items, but it also has some active content (in particular,
> a
> search form).
>
> So my bright idea (tm) (i.e. I'd love to hear critiques before I get too
> far along with it) is the following:
>
> Make a new page for just the data grid, with page parameters including the
> search string and last-modified date (and super-user login because I get
> some edit links and such with that). Mount it and ehcache it, and override
> setHeader so it becomes client cache-able. Then, my outer catalog page
> with the search form on it just uses an IFrame to display the grid data
> (easy to keep track of last-modified globally). Same clear method in DAO
> dumps the cache whenever a change is made.
>
> Also, I'd want to make a robot no-follow thing to avoid google trap on that
> page. Could this actually be a legitimate use of otherwise dodgy IFRAME ?
>
> Sound like a good plan?
>
> Thanks,
> -- Jim.
>
> On Fri, Mar 27, 2009 at 1:56 PM, Jim Pinkham <pi...@gmail.com> wrote:
>
> > Jeremy,
> >
> > Thanks for your thoughtful reply - Scenario is exactly right.
> > I played around with page headers to make the whole page cacheable, but
> ran
> > into several problems - I have a search form, and there's an 'admin'
> login
> > that enables edit links. So it's really a stateful page, but I want to
> > speed up the most common state.
> >
> > The bulk of the content is from an AjaxFallbackDefaultDataTable with
> > sortable columns. I re-sorted a column with the Ajax Debug window open to
> > measure it's data size - about 225000 chars. My database search takes
> > 64ms. Overall client repaint time is about 2 sec with browser on
> > localhost. I haven't found the right hook to measure total wicket
> response
> > time yet, but it appears pretty quick - so that's why I thougth it made
> > sense to focus on client caching.
> >
> > Before I give up entirely on this idea, I'm wondering if it might make
> > sense to make the grid a public Resource, which I'm hoping the browser
> would
> > treat like an image. I can afford a separate db query to just get my
> > max(lastModified), which might let me save the time to generate HTML,
> which
> > looks as though it could be my bottleneck. If this way is too hard, I'll
> > give up, but it sounds do-able - what do you think?
> > Thanks,
> > -- Jim.
> >
> >
> > On Thu, Mar 26, 2009 at 6:30 PM, Jeremy Thomerson <
> > jeremy@wickettraining.com> wrote:
> >
> >> How is this going to help you? Scenario as I understand it:
> >>
> >>
> >> 1. User requests homepage - pulls from site - with your etag in it
> >> 2. User requests homepage again - calls site - your server does all of
> >> the loading of data - then you calculate / set etag
> >> 3. Browser now knows that it is the same as before and does not have
> to
> >> pull the HTML down
> >>
> >> The user saves what is likely a very short time in the overall scheme of
> >> things - downloading the HTML.
> >> The user still has to sit through the process of you loading the data
> from
> >> the search / DB / etc. and generating HTML
> >> Your server saves no load - but a little bandwidth.
> >>
> >> I'd look at caching before it even gets to your server. Otherwise your
> >> user
> >> will likely not see much benefit unless you are sending multiple MB of
> >> data
> >> back. Sounds like premature optimization to me.
> >>
> >> --
> >> Jeremy Thomerson
> >> http://www.wickettraining.com
> >>
> >>
> >>
> >> On Thu, Mar 26, 2009 at 5:26 PM, Jim Pinkham <pi...@gmail.com>
> wrote:
> >>
> >> > Thanks Jerry; I think that applies only to static pages.
> >> >
> >> > My next idea is to try overridding WebPage.setHeaders and just set the
> >> >
> >> > response.setHeader("Cache-Control", "max-age=3600, must-revalidate");
> >> >
> >> > response.setHeader("ETag", "1"); // I'll use a checksum on the data
> >> coming
> >> > back from my search (Even better would be a checksum on the rendered
> >> page
> >> > data - any idea how to do that?)
> >> > Initial test (above) seems promising...
> >> >
> >> > Thanks,
> >> > -- Jim.
> >> >
> >> > On Thu, Mar 26, 2009 at 3:22 PM, Jeremy Thomerson <
> >> > jeremy@wickettraining.com
> >> > > wrote:
> >> >
> >> > > Have you looked at a standard HTTP caching proxy like
> >> > > http://www.squid-cache.org/ ?
> >> > >
> >> > >
> >> > > --
> >> > > Jeremy Thomerson
> >> > > http://www.wickettraining.com
> >> > >
> >> > >
> >> > >
> >> > > On Thu, Mar 26, 2009 at 2:02 PM, Jim Pinkham <pi...@gmail.com>
> >> wrote:
> >> > >
> >> > > > Changing my search query to this got some better hits:
> >> > > > http://lmgtfy.com/?q=cacheability
> >> > > > So, allow me to refine my question based on that - has anyone
> tried
> >> > some
> >> > > of
> >> > > > these approaches (see first result from above) to generrate and
> dump
> >> > > > content
> >> > > > to a static file (renamed if it chages) and having the wicket home
> >> page
> >> > > be
> >> > > > a
> >> > > > redirect to that file, or something like that?
> >> > > >
> >> > > > Thanks,
> >> > > > -- Jim.
> >> > > > On Thu, Mar 26, 2009 at 12:53 PM, Jim Pinkham <pinkhamj@gmail.com
> >
> >> > > wrote:
> >> > > >
> >> > > > > I've found a few posts about how to mark dynamic pages so they
> >> won't
> >> > be
> >> > > > > cached.
> >> > > > >
> >> > > > > I've got a different situation that I think is fairly common -
> the
> >> > > 'home'
> >> > > > > page of my app is effectively a (cheesr-like) catalog of items
> >> that
> >> > > > changes
> >> > > > > infrequently. Users didn't like paging, so it's about 300
> items
> >> in
> >> > a
> >> > > > > simple scrollable page. Once a user views it, they often drill
> >> down
> >> > > into
> >> > > > an
> >> > > > > item, then use the back button (or sometimes the Home link) to
> >> > > re-display
> >> > > > > it.
> >> > > > >
> >> > > > > The db query is actually pretty fast; I think the bottleneck
> seems
> >> to
> >> > > be
> >> > > > > fetching the HTML.
> >> > > > >
> >> > > > > My question is, can I use some kind of header caching hint with
> a
> >> > > version
> >> > > > > number so that once the content is identified as being the same
> as
> >> a
> >> > > > > previously fetched page, the user's browser will repaint it from
> a
> >> > > local
> >> > > > > cache? (I know this is typically done with images, but I was
> >> > wondering
> >> > > > if
> >> > > > > this would make sense to do also do with content that
> technically
> >> > > > 'dynamic'
> >> > > > > but actually is 'fairly static' ? (I say version number rather
> >> than
> >> > > > time
> >> > > > > to expire so that in case I add/change an item I can increment
> the
> >> > > > catalog
> >> > > > > version)
> >> > > > >
> >> > > > > Thanks,
> >> > > > > -- Jim
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: Can client cache pages effectively?
Posted by Eduardo Nunes <es...@gmail.com>.
Usually IFrame isn't a good idea, I think it's because of the
accessibility and search engines. At least that is what the major part
of the HTML coders talk about it. But I can't think in another way to
do it. just my 5c
On Thu, Apr 9, 2009 at 1:29 PM, Jim Pinkham <pi...@gmail.com> wrote:
> A quick follow up in case anyone else was curious about how this is going:
>
> I ended up using ehcache page cache filter for a simple page that just
> displays 'current' items (calendar view of events) based on a db query. No
> forms (state) on this page so it works pretty well. In my DAO that does
> updates, I clear the cache. Very simple, works great. (Only catch I ran
> into is that my menus change when I have a session and I'm logged in as
> super-user, so I have to make sure I don't let that version of the page be
> cached - I do that by adding 'super' page parameter so URL is different
> and filter is set to only cache the 'normal' version.
>
> So, that still leaves me with my main catalog page, which is primarily a
> similar list of items, but it also has some active content (in particular, a
> search form).
>
> So my bright idea (tm) (i.e. I'd love to hear critiques before I get too
> far along with it) is the following:
>
> Make a new page for just the data grid, with page parameters including the
> search string and last-modified date (and super-user login because I get
> some edit links and such with that). Mount it and ehcache it, and override
> setHeader so it becomes client cache-able. Then, my outer catalog page
> with the search form on it just uses an IFrame to display the grid data
> (easy to keep track of last-modified globally). Same clear method in DAO
> dumps the cache whenever a change is made.
>
> Also, I'd want to make a robot no-follow thing to avoid google trap on that
> page. Could this actually be a legitimate use of otherwise dodgy IFRAME ?
>
> Sound like a good plan?
>
> Thanks,
> -- Jim.
>
> On Fri, Mar 27, 2009 at 1:56 PM, Jim Pinkham <pi...@gmail.com> wrote:
>
>> Jeremy,
>>
>> Thanks for your thoughtful reply - Scenario is exactly right.
>> I played around with page headers to make the whole page cacheable, but ran
>> into several problems - I have a search form, and there's an 'admin' login
>> that enables edit links. So it's really a stateful page, but I want to
>> speed up the most common state.
>>
>> The bulk of the content is from an AjaxFallbackDefaultDataTable with
>> sortable columns. I re-sorted a column with the Ajax Debug window open to
>> measure it's data size - about 225000 chars. My database search takes
>> 64ms. Overall client repaint time is about 2 sec with browser on
>> localhost. I haven't found the right hook to measure total wicket response
>> time yet, but it appears pretty quick - so that's why I thougth it made
>> sense to focus on client caching.
>>
>> Before I give up entirely on this idea, I'm wondering if it might make
>> sense to make the grid a public Resource, which I'm hoping the browser would
>> treat like an image. I can afford a separate db query to just get my
>> max(lastModified), which might let me save the time to generate HTML, which
>> looks as though it could be my bottleneck. If this way is too hard, I'll
>> give up, but it sounds do-able - what do you think?
>> Thanks,
>> -- Jim.
>>
>>
>> On Thu, Mar 26, 2009 at 6:30 PM, Jeremy Thomerson <
>> jeremy@wickettraining.com> wrote:
>>
>>> How is this going to help you? Scenario as I understand it:
>>>
>>>
>>> 1. User requests homepage - pulls from site - with your etag in it
>>> 2. User requests homepage again - calls site - your server does all of
>>> the loading of data - then you calculate / set etag
>>> 3. Browser now knows that it is the same as before and does not have to
>>> pull the HTML down
>>>
>>> The user saves what is likely a very short time in the overall scheme of
>>> things - downloading the HTML.
>>> The user still has to sit through the process of you loading the data from
>>> the search / DB / etc. and generating HTML
>>> Your server saves no load - but a little bandwidth.
>>>
>>> I'd look at caching before it even gets to your server. Otherwise your
>>> user
>>> will likely not see much benefit unless you are sending multiple MB of
>>> data
>>> back. Sounds like premature optimization to me.
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>>>
>>> On Thu, Mar 26, 2009 at 5:26 PM, Jim Pinkham <pi...@gmail.com> wrote:
>>>
>>> > Thanks Jerry; I think that applies only to static pages.
>>> >
>>> > My next idea is to try overridding WebPage.setHeaders and just set the
>>> >
>>> > response.setHeader("Cache-Control", "max-age=3600, must-revalidate");
>>> >
>>> > response.setHeader("ETag", "1"); // I'll use a checksum on the data
>>> coming
>>> > back from my search (Even better would be a checksum on the rendered
>>> page
>>> > data - any idea how to do that?)
>>> > Initial test (above) seems promising...
>>> >
>>> > Thanks,
>>> > -- Jim.
>>> >
>>> > On Thu, Mar 26, 2009 at 3:22 PM, Jeremy Thomerson <
>>> > jeremy@wickettraining.com
>>> > > wrote:
>>> >
>>> > > Have you looked at a standard HTTP caching proxy like
>>> > > http://www.squid-cache.org/ ?
>>> > >
>>> > >
>>> > > --
>>> > > Jeremy Thomerson
>>> > > http://www.wickettraining.com
>>> > >
>>> > >
>>> > >
>>> > > On Thu, Mar 26, 2009 at 2:02 PM, Jim Pinkham <pi...@gmail.com>
>>> wrote:
>>> > >
>>> > > > Changing my search query to this got some better hits:
>>> > > > http://lmgtfy.com/?q=cacheability
>>> > > > So, allow me to refine my question based on that - has anyone tried
>>> > some
>>> > > of
>>> > > > these approaches (see first result from above) to generrate and dump
>>> > > > content
>>> > > > to a static file (renamed if it chages) and having the wicket home
>>> page
>>> > > be
>>> > > > a
>>> > > > redirect to that file, or something like that?
>>> > > >
>>> > > > Thanks,
>>> > > > -- Jim.
>>> > > > On Thu, Mar 26, 2009 at 12:53 PM, Jim Pinkham <pi...@gmail.com>
>>> > > wrote:
>>> > > >
>>> > > > > I've found a few posts about how to mark dynamic pages so they
>>> won't
>>> > be
>>> > > > > cached.
>>> > > > >
>>> > > > > I've got a different situation that I think is fairly common - the
>>> > > 'home'
>>> > > > > page of my app is effectively a (cheesr-like) catalog of items
>>> that
>>> > > > changes
>>> > > > > infrequently. Users didn't like paging, so it's about 300 items
>>> in
>>> > a
>>> > > > > simple scrollable page. Once a user views it, they often drill
>>> down
>>> > > into
>>> > > > an
>>> > > > > item, then use the back button (or sometimes the Home link) to
>>> > > re-display
>>> > > > > it.
>>> > > > >
>>> > > > > The db query is actually pretty fast; I think the bottleneck seems
>>> to
>>> > > be
>>> > > > > fetching the HTML.
>>> > > > >
>>> > > > > My question is, can I use some kind of header caching hint with a
>>> > > version
>>> > > > > number so that once the content is identified as being the same as
>>> a
>>> > > > > previously fetched page, the user's browser will repaint it from a
>>> > > local
>>> > > > > cache? (I know this is typically done with images, but I was
>>> > wondering
>>> > > > if
>>> > > > > this would make sense to do also do with content that technically
>>> > > > 'dynamic'
>>> > > > > but actually is 'fairly static' ? (I say version number rather
>>> than
>>> > > > time
>>> > > > > to expire so that in case I add/change an item I can increment the
>>> > > > catalog
>>> > > > > version)
>>> > > > >
>>> > > > > Thanks,
>>> > > > > -- Jim
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org