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 > > > > > > > > > >
