You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Jared Ocker <oc...@ohsu.edu> on 2014/10/10 00:53:56 UTC
stale-while-revalidate not always serving stale content
We have the stale-while-revalidate plugin in place and have noticed some behavior that seems suboptimal. While cache is fresh, everything works great. The first page hit after our 300sec s-maxage has passed comes back with “Warning: 110 Response is stale” as expected. However, it appears to be deleting the cached file and then looking at the origin server to pull fresh content. Our origin servers aren’t exactly fast (hence the need for ATS), so this results in about 4 sec of time while that cache file doesn’t exist and any hits to that page need to wait for the content from the origin server.
Additional information:
s-maxage=300
stale-while-revalidate=604800
stale-if-error=31536000
When Age < s-maxage:
* Via: ApacheTrafficServer/4.2.0 [cHs f]
First page load after Age > s-maxage:
* Via: ApacheTrafficServer/4.2.0 [cHs f]
* Warning: 110 Response is stale
At this point, Cache Inspector shows the cached file to be missing for 3-4 seconds
Subsequent page loads during revalidation process:
* Via: ApacheTrafficServer/4.2.0 [cMs Sf]
* This page load also shows a cookie being loaded that only comes from our origin servers
After the 3-4 second revalidation process, everything seems to go back to normal.
I might just be missing something but this doesn’t appear to be working as designed. Does anyone know how I can get it to continue showing stale cache during the entire revalidation process?
Thanks,
.: Jared
Re: stale-while-revalidate not always serving stale content
Posted by Igor Brezac <ig...@ypass.net>.
+1
Thanks,
-Igor
On Fri, Oct 10, 2014 at 10:32 AM, Jared Ocker <oc...@ohsu.edu> wrote:
> That would be fantastic. If there¹s anything we can do to help expedite
> the open sourcing, please let me know. This has definitely been a pain
> point for us.
>
> Thanks,
> .: Jared
>
> On 10/9/14, 8:48 PM, "Sudheer Vinukonda" <su...@yahoo-inc.com.INVALID>
> wrote:
>
> >Hi Leif and all,
> >
> >Just fyi, We have an enhanced version of the plugin, that we use
> >internally that works around these limitations and is able to serve the
> >stale copy to successive requests until a fresher copy is available.
> >
> >We may work on open sourcing that version soon, if time permits.
> >
> >
> >Thanks,
> >
> >Sudheer
> >
> >> On Oct 9, 2014, at 8:45 PM, "Sudheer Vinukonda"
> >><su...@yahoo-inc.com> wrote:
> >>
> >>
> >>
> >>> On Oct 9, 2014, at 8:39 PM, "Leif Hedstrom" <zw...@apache.org> wrote:
> >>>
> >>>
> >>>> On Oct 9, 2014, at 6:08 PM, Shu Kit Chan <ch...@gmail.com>
> wrote:
> >>>>
> >>>> It seems to be similar to this jira ticket -
> >>>> https://issues.apache.org/jira/browse/TS-1463
> >>>
> >>> Yeah, Kit is spot on. This is a known problem with the plugin, and
> >>>it¹s an artifact of how the ATS cache works. To be able to implement
> >>>stale-while-revalidate, we¹d need to make changes in the cache such
> >>>that it does not update the dir entries etc. until the ³new² version is
> >>>available to be served. Alan?
> >>>
> >>> ‹ leif
> >>>
> >>>>
> >>>> Kit
> >>>>
> >>>>> On Thu, Oct 9, 2014 at 3:53 PM, Jared Ocker <oc...@ohsu.edu> wrote:
> >>>>>
> >>>>> We have the stale-while-revalidate plugin in place and have noticed
> >>>>>some
> >>>>> behavior that seems suboptimal. While cache is fresh, everything
> >>>>>works
> >>>>> great. The first page hit after our 300sec s-maxage has passed
> >>>>>comes back
> >>>>> with ³Warning: 110 Response is stale² as expected. However, it
> >>>>>appears to
> >>>>> be deleting the cached file and then looking at the origin server to
> >>>>>pull
> >>>>> fresh content. Our origin servers aren¹t exactly fast (hence the
> >>>>>need for
> >>>>> ATS), so this results in about 4 sec of time while that cache file
> >>>>>doesn¹t
> >>>>> exist and any hits to that page need to wait for the content from the
> >>>>> origin server.
> >>>>>
> >>>>> Additional information:
> >>>>> s-maxage=300
> >>>>> stale-while-revalidate=604800
> >>>>> stale-if-error=31536000
> >>>>>
> >>>>> When Age < s-maxage:
> >>>>>
> >>>>> * Via: ApacheTrafficServer/4.2.0 [cHs f]
> >>>>>
> >>>>> First page load after Age > s-maxage:
> >>>>>
> >>>>> * Via: ApacheTrafficServer/4.2.0 [cHs f]
> >>>>> * Warning: 110 Response is stale
> >>>>>
> >>>>> At this point, Cache Inspector shows the cached file to be missing
> >>>>>for 3-4
> >>>>> seconds
> >>>>>
> >>>>> Subsequent page loads during revalidation process:
> >>>>>
> >>>>> * Via: ApacheTrafficServer/4.2.0 [cMs Sf]
> >>>>> * This page load also shows a cookie being loaded that only comes
> >>>>>from
> >>>>> our origin servers
> >>>>>
> >>>>> After the 3-4 second revalidation process, everything seems to go
> >>>>>back to
> >>>>> normal.
> >>>>>
> >>>>> I might just be missing something but this doesn¹t appear to be
> >>>>>working as
> >>>>> designed. Does anyone know how I can get it to continue showing
> >>>>>stale
> >>>>> cache during the entire revalidation process?
> >>>>>
> >>>>> Thanks,
> >>>>> .: Jared
> >>>
>
>
Re: stale-while-revalidate not always serving stale content
Posted by Jared Ocker <oc...@ohsu.edu>.
That would be fantastic. If there¹s anything we can do to help expedite
the open sourcing, please let me know. This has definitely been a pain
point for us.
Thanks,
.: Jared
On 10/9/14, 8:48 PM, "Sudheer Vinukonda" <su...@yahoo-inc.com.INVALID>
wrote:
>Hi Leif and all,
>
>Just fyi, We have an enhanced version of the plugin, that we use
>internally that works around these limitations and is able to serve the
>stale copy to successive requests until a fresher copy is available.
>
>We may work on open sourcing that version soon, if time permits.
>
>
>Thanks,
>
>Sudheer
>
>> On Oct 9, 2014, at 8:45 PM, "Sudheer Vinukonda"
>><su...@yahoo-inc.com> wrote:
>>
>>
>>
>>> On Oct 9, 2014, at 8:39 PM, "Leif Hedstrom" <zw...@apache.org> wrote:
>>>
>>>
>>>> On Oct 9, 2014, at 6:08 PM, Shu Kit Chan <ch...@gmail.com> wrote:
>>>>
>>>> It seems to be similar to this jira ticket -
>>>> https://issues.apache.org/jira/browse/TS-1463
>>>
>>> Yeah, Kit is spot on. This is a known problem with the plugin, and
>>>it¹s an artifact of how the ATS cache works. To be able to implement
>>>stale-while-revalidate, we¹d need to make changes in the cache such
>>>that it does not update the dir entries etc. until the ³new² version is
>>>available to be served. Alan?
>>>
>>> ‹ leif
>>>
>>>>
>>>> Kit
>>>>
>>>>> On Thu, Oct 9, 2014 at 3:53 PM, Jared Ocker <oc...@ohsu.edu> wrote:
>>>>>
>>>>> We have the stale-while-revalidate plugin in place and have noticed
>>>>>some
>>>>> behavior that seems suboptimal. While cache is fresh, everything
>>>>>works
>>>>> great. The first page hit after our 300sec s-maxage has passed
>>>>>comes back
>>>>> with ³Warning: 110 Response is stale² as expected. However, it
>>>>>appears to
>>>>> be deleting the cached file and then looking at the origin server to
>>>>>pull
>>>>> fresh content. Our origin servers aren¹t exactly fast (hence the
>>>>>need for
>>>>> ATS), so this results in about 4 sec of time while that cache file
>>>>>doesn¹t
>>>>> exist and any hits to that page need to wait for the content from the
>>>>> origin server.
>>>>>
>>>>> Additional information:
>>>>> s-maxage=300
>>>>> stale-while-revalidate=604800
>>>>> stale-if-error=31536000
>>>>>
>>>>> When Age < s-maxage:
>>>>>
>>>>> * Via: ApacheTrafficServer/4.2.0 [cHs f]
>>>>>
>>>>> First page load after Age > s-maxage:
>>>>>
>>>>> * Via: ApacheTrafficServer/4.2.0 [cHs f]
>>>>> * Warning: 110 Response is stale
>>>>>
>>>>> At this point, Cache Inspector shows the cached file to be missing
>>>>>for 3-4
>>>>> seconds
>>>>>
>>>>> Subsequent page loads during revalidation process:
>>>>>
>>>>> * Via: ApacheTrafficServer/4.2.0 [cMs Sf]
>>>>> * This page load also shows a cookie being loaded that only comes
>>>>>from
>>>>> our origin servers
>>>>>
>>>>> After the 3-4 second revalidation process, everything seems to go
>>>>>back to
>>>>> normal.
>>>>>
>>>>> I might just be missing something but this doesn¹t appear to be
>>>>>working as
>>>>> designed. Does anyone know how I can get it to continue showing
>>>>>stale
>>>>> cache during the entire revalidation process?
>>>>>
>>>>> Thanks,
>>>>> .: Jared
>>>
Re: stale-while-revalidate not always serving stale content
Posted by Sudheer Vinukonda <su...@yahoo-inc.com.INVALID>.
Hi Leif and all,
Just fyi, We have an enhanced version of the plugin, that we use internally that works around these limitations and is able to serve the stale copy to successive requests until a fresher copy is available.
We may work on open sourcing that version soon, if time permits.
Thanks,
Sudheer
> On Oct 9, 2014, at 8:45 PM, "Sudheer Vinukonda" <su...@yahoo-inc.com> wrote:
>
>
>
>> On Oct 9, 2014, at 8:39 PM, "Leif Hedstrom" <zw...@apache.org> wrote:
>>
>>
>>> On Oct 9, 2014, at 6:08 PM, Shu Kit Chan <ch...@gmail.com> wrote:
>>>
>>> It seems to be similar to this jira ticket -
>>> https://issues.apache.org/jira/browse/TS-1463
>>
>> Yeah, Kit is spot on. This is a known problem with the plugin, and it’s an artifact of how the ATS cache works. To be able to implement stale-while-revalidate, we’d need to make changes in the cache such that it does not update the dir entries etc. until the “new” version is available to be served. Alan?
>>
>> — leif
>>
>>>
>>> Kit
>>>
>>>> On Thu, Oct 9, 2014 at 3:53 PM, Jared Ocker <oc...@ohsu.edu> wrote:
>>>>
>>>> We have the stale-while-revalidate plugin in place and have noticed some
>>>> behavior that seems suboptimal. While cache is fresh, everything works
>>>> great. The first page hit after our 300sec s-maxage has passed comes back
>>>> with “Warning: 110 Response is stale” as expected. However, it appears to
>>>> be deleting the cached file and then looking at the origin server to pull
>>>> fresh content. Our origin servers aren’t exactly fast (hence the need for
>>>> ATS), so this results in about 4 sec of time while that cache file doesn’t
>>>> exist and any hits to that page need to wait for the content from the
>>>> origin server.
>>>>
>>>> Additional information:
>>>> s-maxage=300
>>>> stale-while-revalidate=604800
>>>> stale-if-error=31536000
>>>>
>>>> When Age < s-maxage:
>>>>
>>>> * Via: ApacheTrafficServer/4.2.0 [cHs f]
>>>>
>>>> First page load after Age > s-maxage:
>>>>
>>>> * Via: ApacheTrafficServer/4.2.0 [cHs f]
>>>> * Warning: 110 Response is stale
>>>>
>>>> At this point, Cache Inspector shows the cached file to be missing for 3-4
>>>> seconds
>>>>
>>>> Subsequent page loads during revalidation process:
>>>>
>>>> * Via: ApacheTrafficServer/4.2.0 [cMs Sf]
>>>> * This page load also shows a cookie being loaded that only comes from
>>>> our origin servers
>>>>
>>>> After the 3-4 second revalidation process, everything seems to go back to
>>>> normal.
>>>>
>>>> I might just be missing something but this doesn’t appear to be working as
>>>> designed. Does anyone know how I can get it to continue showing stale
>>>> cache during the entire revalidation process?
>>>>
>>>> Thanks,
>>>> .: Jared
>>
Re: stale-while-revalidate not always serving stale content
Posted by Sudheer Vinukonda <su...@yahoo-inc.com.INVALID>.
> On Oct 9, 2014, at 8:39 PM, "Leif Hedstrom" <zw...@apache.org> wrote:
>
>
>> On Oct 9, 2014, at 6:08 PM, Shu Kit Chan <ch...@gmail.com> wrote:
>>
>> It seems to be similar to this jira ticket -
>> https://issues.apache.org/jira/browse/TS-1463
>
> Yeah, Kit is spot on. This is a known problem with the plugin, and it’s an artifact of how the ATS cache works. To be able to implement stale-while-revalidate, we’d need to make changes in the cache such that it does not update the dir entries etc. until the “new” version is available to be served. Alan?
>
> — leif
>
>>
>> Kit
>>
>>> On Thu, Oct 9, 2014 at 3:53 PM, Jared Ocker <oc...@ohsu.edu> wrote:
>>>
>>> We have the stale-while-revalidate plugin in place and have noticed some
>>> behavior that seems suboptimal. While cache is fresh, everything works
>>> great. The first page hit after our 300sec s-maxage has passed comes back
>>> with “Warning: 110 Response is stale” as expected. However, it appears to
>>> be deleting the cached file and then looking at the origin server to pull
>>> fresh content. Our origin servers aren’t exactly fast (hence the need for
>>> ATS), so this results in about 4 sec of time while that cache file doesn’t
>>> exist and any hits to that page need to wait for the content from the
>>> origin server.
>>>
>>> Additional information:
>>> s-maxage=300
>>> stale-while-revalidate=604800
>>> stale-if-error=31536000
>>>
>>> When Age < s-maxage:
>>>
>>> * Via: ApacheTrafficServer/4.2.0 [cHs f]
>>>
>>> First page load after Age > s-maxage:
>>>
>>> * Via: ApacheTrafficServer/4.2.0 [cHs f]
>>> * Warning: 110 Response is stale
>>>
>>> At this point, Cache Inspector shows the cached file to be missing for 3-4
>>> seconds
>>>
>>> Subsequent page loads during revalidation process:
>>>
>>> * Via: ApacheTrafficServer/4.2.0 [cMs Sf]
>>> * This page load also shows a cookie being loaded that only comes from
>>> our origin servers
>>>
>>> After the 3-4 second revalidation process, everything seems to go back to
>>> normal.
>>>
>>> I might just be missing something but this doesn’t appear to be working as
>>> designed. Does anyone know how I can get it to continue showing stale
>>> cache during the entire revalidation process?
>>>
>>> Thanks,
>>> .: Jared
>
Re: stale-while-revalidate not always serving stale content
Posted by "Alan M. Carroll" <am...@network-geographics.com>.
Thursday, October 9, 2014, 10:39:01 PM, you wrote:
> On Oct 9, 2014, at 6:08 PM, Shu Kit Chan <ch...@gmail.com> wrote:
>> It seems to be similar to this jira ticket -
>> https://issues.apache.org/jira/browse/TS-1463
> Yeah, Kit is spot on. This is a known problem with the plugin, and it’s an artifact of how the ATS cache works. To be able to implement stale-while-revalidate, we’d need to make changes in the cache such that it does not update the dir entries etc. until the “new” version is available to be served. Alan?
This has come up locally as well so I will see if I can put in the real fix.
Re: stale-while-revalidate not always serving stale content
Posted by Leif Hedstrom <zw...@apache.org>.
On Oct 9, 2014, at 6:08 PM, Shu Kit Chan <ch...@gmail.com> wrote:
> It seems to be similar to this jira ticket -
> https://issues.apache.org/jira/browse/TS-1463
Yeah, Kit is spot on. This is a known problem with the plugin, and it’s an artifact of how the ATS cache works. To be able to implement stale-while-revalidate, we’d need to make changes in the cache such that it does not update the dir entries etc. until the “new” version is available to be served. Alan?
— leif
>
> Kit
>
> On Thu, Oct 9, 2014 at 3:53 PM, Jared Ocker <oc...@ohsu.edu> wrote:
>
>> We have the stale-while-revalidate plugin in place and have noticed some
>> behavior that seems suboptimal. While cache is fresh, everything works
>> great. The first page hit after our 300sec s-maxage has passed comes back
>> with “Warning: 110 Response is stale” as expected. However, it appears to
>> be deleting the cached file and then looking at the origin server to pull
>> fresh content. Our origin servers aren’t exactly fast (hence the need for
>> ATS), so this results in about 4 sec of time while that cache file doesn’t
>> exist and any hits to that page need to wait for the content from the
>> origin server.
>>
>> Additional information:
>> s-maxage=300
>> stale-while-revalidate=604800
>> stale-if-error=31536000
>>
>> When Age < s-maxage:
>>
>> * Via: ApacheTrafficServer/4.2.0 [cHs f]
>>
>> First page load after Age > s-maxage:
>>
>> * Via: ApacheTrafficServer/4.2.0 [cHs f]
>> * Warning: 110 Response is stale
>>
>> At this point, Cache Inspector shows the cached file to be missing for 3-4
>> seconds
>>
>> Subsequent page loads during revalidation process:
>>
>> * Via: ApacheTrafficServer/4.2.0 [cMs Sf]
>> * This page load also shows a cookie being loaded that only comes from
>> our origin servers
>>
>> After the 3-4 second revalidation process, everything seems to go back to
>> normal.
>>
>> I might just be missing something but this doesn’t appear to be working as
>> designed. Does anyone know how I can get it to continue showing stale
>> cache during the entire revalidation process?
>>
>> Thanks,
>> .: Jared
>>
Re: stale-while-revalidate not always serving stale content
Posted by Shu Kit Chan <ch...@gmail.com>.
It seems to be similar to this jira ticket -
https://issues.apache.org/jira/browse/TS-1463
Kit
On Thu, Oct 9, 2014 at 3:53 PM, Jared Ocker <oc...@ohsu.edu> wrote:
> We have the stale-while-revalidate plugin in place and have noticed some
> behavior that seems suboptimal. While cache is fresh, everything works
> great. The first page hit after our 300sec s-maxage has passed comes back
> with “Warning: 110 Response is stale” as expected. However, it appears to
> be deleting the cached file and then looking at the origin server to pull
> fresh content. Our origin servers aren’t exactly fast (hence the need for
> ATS), so this results in about 4 sec of time while that cache file doesn’t
> exist and any hits to that page need to wait for the content from the
> origin server.
>
> Additional information:
> s-maxage=300
> stale-while-revalidate=604800
> stale-if-error=31536000
>
> When Age < s-maxage:
>
> * Via: ApacheTrafficServer/4.2.0 [cHs f]
>
> First page load after Age > s-maxage:
>
> * Via: ApacheTrafficServer/4.2.0 [cHs f]
> * Warning: 110 Response is stale
>
> At this point, Cache Inspector shows the cached file to be missing for 3-4
> seconds
>
> Subsequent page loads during revalidation process:
>
> * Via: ApacheTrafficServer/4.2.0 [cMs Sf]
> * This page load also shows a cookie being loaded that only comes from
> our origin servers
>
> After the 3-4 second revalidation process, everything seems to go back to
> normal.
>
> I might just be missing something but this doesn’t appear to be working as
> designed. Does anyone know how I can get it to continue showing stale
> cache during the entire revalidation process?
>
> Thanks,
> .: Jared
>