On 6/11/12 5:34 PM, James Peach wrote: > On 11/06/2012, at 4:23 PM, 오재경 wrote: > >> Hi. >> >> we have an serious issue. we have a customer site whose service is online >> learning and it provides registered members with a player. the player sends >> range request. >> >> Now you can guess what problem I confront. we have to cache contents but >> because of the range request traffic server can’t cache whole content. >> It doesn’t matter whether we set background_fill_completed_threshold to >> 0.00 or not. > Have you tested with 3.1.4? There have been some improvements to range > request handling in that release. >
Unfortunately, those fixes doesn't help this. The problem is documented in at least one bug, e.g. https://issues.apache.org/jira/browse/TS-683 Another option that I've been pondering, which is more suitable for large contents I think, is to kick off background requests for the full objects. A plugin that does something like: 1) In read-response-header hook, if the object is a Range response, *and* it's cacheable, schedule a background load on the task threads. This obviously has to be done in a way that the same request is only fetched one, effectively "locking" it. 2) On the task threads, we do a fetch through the SM for the URL, without a Range header. We simply discard the results. 3) While the background fetch is happening, client Range: requests for those objects continue to be proxied as before. 4) (possibly, not sure if it's doable without core changes, but we might consider this): If an object is partially written in cache, and a Range: request can be fully satisfied with what we already have in cache, server out of the cache. This is similar to our read-while-writer feature. A background fill feature like this is useful also as a "generic" tool, so maybe the feature should go into core. That way, a plugin for these range request fills can use that, as well as e.g. a serve-while-revalidate plugin (as an example). I'm sure there could be other reasons why someone would want to kick off a background fill request, which is disconnected from any client sessions (i.e. there's only a blackhole consumer of the VC). Thoughts? -- leif
