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 <[email protected] > 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 <[email protected]> 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 < > > [email protected] > > > 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 <[email protected]> > 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 <[email protected]> > > > 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 > > > > > > > > > > > > > > >
