On 07/11/2014 08:19 PM, Amos Jeffries wrote: > 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
post-cache RESPMOD cannot cache something because it operates on the other side of the cache. Among the two RESPMODs, only pre-cache RESPMOD can cache. There is no need for RESPMOD to cache the large unfiltered object. That happens without adaptation. > and > Squid cache supplying it to the adaptation module for each adaptation task. That is possible if one implements post-cache RESPMOD. Unfortunately, both large Squid hits and PageSpeed adaptations are too slow to be used like that. For performance reasons, folks want to cache the adapted variants in the Squid cache. > 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. No, it does not work like that. Please see my description in the response to Christos (and also below) for details on how a post-cache REQMOD may work to accommodate PageSpeed needs. > 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. No, the pre-cache RESPMOD service temporary stores the small adapted content (possibly many variants!) in its own cache, not the large virgin content. Post-cache REQMOD service delivers the right adapted variant to Squid, which caches it in Squid cache, and delivers it to the client. > 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. Or there may be no good place to store pre-created shrunk variants and/or pick the right variant on the origin server.Or the proxy people may not have much control over the origin server, even if both belong to the same [large] organization. Or the server is too far, too slow, too overloaded with more important stuff, etc. > Vary caching is after all the design of providing client-specific > variants without all the work of realtime adaptation. The solution I sketched may use Vary when storing variants in Squid cache. Vary is a useful mechanism and post-cache REQMOD does not preclude its use. Hope this clarifies, Alex.
