On 12/07/2014 2:47 a.m., Alex Rousskov wrote: > On 07/11/2014 05:27 AM, Tsantilas Christos wrote: > >> The PageSpeed example fits better to a post-cache RESPMOD feature. > > I do not think so. Post-cache RESPMOD does not allow Squid to cache the > adapted variants. Please let me know if I missed how post-cache RESPMOD > can do that.
post-cache RESPMOD should be caching the large unfiltered object and Squid cache supplying it to the adaptation module for each adaptation task. Adaptation operations on each request, but no upstream contact necessary. post-cache REQMOD the cache stores the shrunk version of objects. Adaptors at this point cannot pull form cache, so request the larger object from upstream on each MISS in order to adapt befor caching. Adaptation operations only on MISS, but upstream fetch of the unfiltered large object on each adaptation. I guess you are assuming that the ICAP service stores the unfiltered object in its own cache and delivers the shrunk objects to Squid as reply responses to REQMOD. This is the only case in which post-cache REQMOD is more efficient overall than pre-cache REQMOD. > > The key here is that PageSpeed and similar services want to create (and > cache) many adapted responses out of a single virgin response. Neither > HTTP itself nor the Squid architecture support that well. Post-cache > REQMOD allows basic PageSpeed support (the first request for "small" > adapted content gets "large" virgin content, but the second request for > small content fetches it from the PageSpeed cache, storing it in Squid > cache). To optimize PageSpeed support further (so that the first request > can get small content), we will need to add another generally useful > feature, but I would rather not bring it into this discussion (there > will be a separate RFC if we get that far). > > The alternative is to create a completely new interface (not a true > vectoring point) that allows an adaptation service to push multiple > adapted responses into the Squid cache _and_ tell Squid which of those > responses to use for the current request. While I have considered > proposing that, I still think we would be better off supporting > "standard" and "well understood" building blocks (such as standard > adaptation vectoring points) rather than such highly-specialized > interfaces. Please let me know if you disagree. > IMHO if this feature is provided the persons requesting it will find that PageSpeed works no faster than pre-created shrunk variants over standard HTTP with working Vary caching. They are saving cheap disk storage by spending expensive CPU and network latency. Probably in an effort to speed up all those very old proxies that incorrectly implement Cache-Control:no-cache. Vary caching is after all the design of providing client-specific variants without all the work of realtime adaptation. (thats just me getting old though as I look desparingly on an ever more inefficient network - "back in my day..."). > >> Is >> the post-cacge REQMOD just a first step to support all post-cache >> vectoring points? > > You can certainly view it that way, but I do not propose or promise > adding post-cache RESPMOD :-). > > > Thank you, > > Alex. Amos
