>There is a huge amount of logic about deciding what to cache with quite a lot of tunable parameters. In addition most serious users develop their own plugins to control caching logic (all the clients I have worked for have done so). You could start with looking through the documentation for cache.config and remap.config. There is also the issue of how much attention to pay to the HTTP specifications about what can be cached (ATS lets you tune that, by default it obeys the specs).
in the context of range requests I understand that the logic about what files to cache may be overriden inside plugins. Who currently does the actual work of retrieving the file to be cached and placing it into the cache? I would assume it is the Core who does this if the plugin instructs it to do so. If this assumption is true would it be a valid option to allow the plugin to decide what part of the file should be cached? (by default the whole file would be cached like now). This way we could implement a plugin which is also able to decide to cache ranges of files. Can also a plugin decide if an entry from the cache should or should not be used? More exactly: is a plugin capable of combining a number of cache entries and serving the result as a response? >In practice, because ATS does not by default cache "cgi looking" URLs very few video files will be cached. Certainly nothing from YouTube, for instance, unless you write a customized plugin to do so (you might search the email archives for discussions on that subject*). People who write such plugins also tend to build large caches (10s of TBs, or more) and people who don't end up (in general) not caching video files. I think writing a plugin is OK. >* Most (all?) streaming video servers encode a lot of data in the URL so that if you try to cache by URL naively you'll cache the same video multiple times and also get very few to no cache hits for all your effort. Something to keep in mind if you ever try to test your changes. We'll definetely consider this. >You should definitely checkout the range changes I posted recently to the list because that will impact your work. The use of alternates for content objects is a key feature that must be supported. OK. On Wed, Aug 22, 2012 at 1:31 AM, Alan M. Carroll < a...@network-geographics.com> wrote: > Tuesday, August 21, 2012, 2:43:06 PM, you wrote: > > > Thank you Alan for stepping in! > > >>>ATS will only cache full object requests. It never caches range > requests. > > > Is this happening also for large files (video files for example) ? I > assume > > that the cache will fill up quite quickly with this approach, isn't it? > > What is currently the strategy used for deciding which files get cached > and > > which do not? > > There is a huge amount of logic about deciding what to cache with quite a > lot of tunable parameters. In addition most serious users develop their own > plugins to control caching logic (all the clients I have worked for have > done so). You could start with looking through the documentation for > cache.config and remap.config. There is also the issue of how much > attention to pay to the HTTP specifications about what can be cached (ATS > lets you tune that, by default it obeys the specs). > > In practice, because ATS does not by default cache "cgi looking" URLs very > few video files will be cached. Certainly nothing from YouTube, for > instance, unless you write a customized plugin to do so (you might search > the email archives for discussions on that subject*). People who write such > plugins also tend to build large caches (10s of TBs, or more) and people > who don't end up (in general) not caching video files. > > * Most (all?) streaming video servers encode a lot of data in the URL so > that if you try to cache by URL naively you'll cache the same video > multiple times and also get very few to no cache hits for all your effort. > Something to keep in mind if you ever try to test your changes. > > >>>There is a team somewhere working on caching partial objects but I don't > > know what they current state is. > > > We are currently collecting data from you guys (the ATS developers > mainly) > > about how you envision caching the range requests so we maximize our > > chances of getting our enhancements accepted back into the mainline > project. > > You should definitely checkout the range changes I posted recently to the > list because that will impact your work. The use of alternates for content > objects is a key feature that must be supported. > >
