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