Questions on rfc5861/stale-while-revalidate experimental plugin

[Shu Kit Chan <ch...@gmail.com>]

Hi,

I am trying this plugin out
(https://github.com/apache/trafficserver/tree/master/plugins/experimental/rfc5861)
and I have a few concerns

1) Let's assume that my origin server becomes slow and takes 10
seconds to respond after a while. Initially the origin server response
is fast and cachable (e.g. "Cache-Control: max-age=30,
stale-while-revalidate=300, public") and a cached copy is in the ATS
cache. When the origin server becomes slow and the ATS cache copy
expires, I assume the plugin should be able to return stale response
from ATS and issue an async call to the origin server for the content.
It will continues to give out stale responses from all other requests
of this resource until the origin server comes back 10 seconds later
with the response and cached properly in ATS.

However, I don't think the plugin is doing it this way. The async call
is made in a normal way and thus the cache URL is locked (according to
this diagram - http://trafficserver.apache.org/docs/trunk/sdk/http-hooks-and-transactions/index.en.html).
Subsequent requests to the same resource will get a cache miss and
will be blocked till the origin server comes back with a response 10
seconds later. So in reality, what happened is that once a resource is
expired, the first request for this resource will return with a stale
copy and all subsequent request for this resource will be blocked till
the origin server responds

2) Also, according to TS-998
(https://issues.apache.org/jira/browse/TS-998) , Wouldn't
TSHttpHdrPrint() be causing trouble for the rfc5861 plugin?
I can imagine that it will probably work when pristine_host_hdr is 0,
though. We might be able to construct the async request using
TSMimeHdrPrint() and construct the request line with previously saved
variables.

3) "troot" is a variable used to remember what URL is being called
asynchronously right now. So a subsequent request to ATS will not
generate extra async call of the same URL. But URL is only part of
cache key. Some request headers can be part of the cache key based on
the "Vary" response header.

Thanks.

Kit

Re: Questions on rfc5861/stale-while-revalidate experimental plugin

[Shu Kit Chan <ch...@gmail.com>]

On Wed, Sep 12, 2012 at 7:32 PM, Phil Sorber <so...@apache.org> wrote:
> I opened up a ticket for #1 if you wanted to add anything to it.
>
> https://issues.apache.org/jira/browse/TS-1463

Thanks. I will update that with more comments

>
> On Wed, Sep 12, 2012 at 10:04 PM, Phil Sorber <so...@apache.org> wrote:
>> On Wed, Sep 12, 2012 at 8:48 PM, Shu Kit Chan <ch...@gmail.com> wrote:
>>> Some updates for #1 after some more debugging.
>>>
>>> I was wrong on cache URL being locked. There is no lock or connection
>>> collapse yet. Those subsequent requests for the same resources are
>>> just TCP_MISS, causing extra request to origin server. It is still a
>>> problem, though, because I expect a stale response for these
>>> subsequent requests before the origin responds.
>>
>> Hmm, that's interesting. I agree that is a problem and I will have to
>> look into this further to see how it can be solved. If you have some
>> ideas or a patch I would be very interested in them.
>>
>>>
>>> Thanks
>>>
>>> Kit
>>>
>>> On Wed, Sep 12, 2012 at 9:31 AM, Shu Kit Chan <ch...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I am trying this plugin out
>>>> (https://github.com/apache/trafficserver/tree/master/plugins/experimental/rfc5861)
>>>> and I have a few concerns
>>>>
>>>> 1) Let's assume that my origin server becomes slow and takes 10
>>>> seconds to respond after a while. Initially the origin server response
>>>> is fast and cachable (e.g. "Cache-Control: max-age=30,
>>>> stale-while-revalidate=300, public") and a cached copy is in the ATS
>>>> cache. When the origin server becomes slow and the ATS cache copy
>>>> expires, I assume the plugin should be able to return stale response
>>>> from ATS and issue an async call to the origin server for the content.
>>>> It will continues to give out stale responses from all other requests
>>>> of this resource until the origin server comes back 10 seconds later
>>>> with the response and cached properly in ATS.
>>>>
>>>> However, I don't think the plugin is doing it this way. The async call
>>>> is made in a normal way and thus the cache URL is locked (according to
>>>> this diagram - http://trafficserver.apache.org/docs/trunk/sdk/http-hooks-and-transactions/index.en.html).
>>>> Subsequent requests to the same resource will get a cache miss and
>>>> will be blocked till the origin server comes back with a response 10
>>>> seconds later. So in reality, what happened is that once a resource is
>>>> expired, the first request for this resource will return with a stale
>>>> copy and all subsequent request for this resource will be blocked till
>>>> the origin server responds
>>>>
>>>> 2) Also, according to TS-998
>>>> (https://issues.apache.org/jira/browse/TS-998) , Wouldn't
>>>> TSHttpHdrPrint() be causing trouble for the rfc5861 plugin?
>>>> I can imagine that it will probably work when pristine_host_hdr is 0,
>>>> though. We might be able to construct the async request using
>>>> TSMimeHdrPrint() and construct the request line with previously saved
>>>> variables.
>>>>
>>
>> This is not a problem because we use TSHttpHdrClone() in the
>> TS_HTTP_READ_REQUEST_HDR_HOOK before TS-998 bites us. This isn't ideal
>> because it makes a copy of every single request, but it is the only
>> work around I know of.
>>

Thanks for the explanation.

>>>> 3) "troot" is a variable used to remember what URL is being called
>>>> asynchronously right now. So a subsequent request to ATS will not
>>>> generate extra async call of the same URL. But URL is only part of
>>>> cache key. Some request headers can be part of the cache key based on
>>>> the "Vary" response header.
>>>>
>>
>> Not sure I understand this case. We already did the cache lookup and
>> get back a STALE result so we want to do a fresh lookup to the origin
>> and don't have a 'Vary' response header to to account for. The intent of troot
>> isn't to lock the cache key, just the URL so we don't do multiple
>> requests. If I have missed some case here we can definitely make a
>> change to account for it.
>>

Here is an example
The 2 requests below have the same URL but different cache entry in
ATS if www.example.com is resolving to an ATS server and the response
has a "Vary: Accept-Encoding" response header
curl 'http://www.example.com/'
curl --compressed 'http://www.example.com/

Now assume that both cache copies expires in ATS. Now if we run the
first curl, it will result in an async call. And the second curl will
not result in an async call until the the first curl is finished.

Is this what's going to happen? If it is, is it bad. I am thinking it
is definitely not disastrous, more like a bit undesirable.

>>>> Thanks.
>>>>
>>>> Kit
>>
>> Thanks for the feedback. I'd like to get all the loose ends tied up and
>> see this plugin get some good usage.

Re: Questions on rfc5861/stale-while-revalidate experimental plugin

[Phil Sorber <so...@apache.org>]

I opened up a ticket for #1 if you wanted to add anything to it.

https://issues.apache.org/jira/browse/TS-1463

On Wed, Sep 12, 2012 at 10:04 PM, Phil Sorber <so...@apache.org> wrote:
> On Wed, Sep 12, 2012 at 8:48 PM, Shu Kit Chan <ch...@gmail.com> wrote:
>> Some updates for #1 after some more debugging.
>>
>> I was wrong on cache URL being locked. There is no lock or connection
>> collapse yet. Those subsequent requests for the same resources are
>> just TCP_MISS, causing extra request to origin server. It is still a
>> problem, though, because I expect a stale response for these
>> subsequent requests before the origin responds.
>
> Hmm, that's interesting. I agree that is a problem and I will have to
> look into this further to see how it can be solved. If you have some
> ideas or a patch I would be very interested in them.
>
>>
>> Thanks
>>
>> Kit
>>
>> On Wed, Sep 12, 2012 at 9:31 AM, Shu Kit Chan <ch...@gmail.com> wrote:
>>> Hi,
>>>
>>> I am trying this plugin out
>>> (https://github.com/apache/trafficserver/tree/master/plugins/experimental/rfc5861)
>>> and I have a few concerns
>>>
>>> 1) Let's assume that my origin server becomes slow and takes 10
>>> seconds to respond after a while. Initially the origin server response
>>> is fast and cachable (e.g. "Cache-Control: max-age=30,
>>> stale-while-revalidate=300, public") and a cached copy is in the ATS
>>> cache. When the origin server becomes slow and the ATS cache copy
>>> expires, I assume the plugin should be able to return stale response
>>> from ATS and issue an async call to the origin server for the content.
>>> It will continues to give out stale responses from all other requests
>>> of this resource until the origin server comes back 10 seconds later
>>> with the response and cached properly in ATS.
>>>
>>> However, I don't think the plugin is doing it this way. The async call
>>> is made in a normal way and thus the cache URL is locked (according to
>>> this diagram - http://trafficserver.apache.org/docs/trunk/sdk/http-hooks-and-transactions/index.en.html).
>>> Subsequent requests to the same resource will get a cache miss and
>>> will be blocked till the origin server comes back with a response 10
>>> seconds later. So in reality, what happened is that once a resource is
>>> expired, the first request for this resource will return with a stale
>>> copy and all subsequent request for this resource will be blocked till
>>> the origin server responds
>>>
>>> 2) Also, according to TS-998
>>> (https://issues.apache.org/jira/browse/TS-998) , Wouldn't
>>> TSHttpHdrPrint() be causing trouble for the rfc5861 plugin?
>>> I can imagine that it will probably work when pristine_host_hdr is 0,
>>> though. We might be able to construct the async request using
>>> TSMimeHdrPrint() and construct the request line with previously saved
>>> variables.
>>>
>
> This is not a problem because we use TSHttpHdrClone() in the
> TS_HTTP_READ_REQUEST_HDR_HOOK before TS-998 bites us. This isn't ideal
> because it makes a copy of every single request, but it is the only
> work around I know of.
>
>>> 3) "troot" is a variable used to remember what URL is being called
>>> asynchronously right now. So a subsequent request to ATS will not
>>> generate extra async call of the same URL. But URL is only part of
>>> cache key. Some request headers can be part of the cache key based on
>>> the "Vary" response header.
>>>
>
> Not sure I understand this case. We already did the cache lookup and
> get back a STALE result so we want to do a fresh lookup to the origin
> and don't have a 'Vary' response header to to account for. The intent of troot
> isn't to lock the cache key, just the URL so we don't do multiple
> requests. If I have missed some case here we can definitely make a
> change to account for it.
>
>>> Thanks.
>>>
>>> Kit
>
> Thanks for the feedback. I'd like to get all the loose ends tied up and
> see this plugin get some good usage.

Re: Questions on rfc5861/stale-while-revalidate experimental plugin

[Phil Sorber <so...@apache.org>]

On Wed, Sep 12, 2012 at 8:48 PM, Shu Kit Chan <ch...@gmail.com> wrote:
> Some updates for #1 after some more debugging.
>
> I was wrong on cache URL being locked. There is no lock or connection
> collapse yet. Those subsequent requests for the same resources are
> just TCP_MISS, causing extra request to origin server. It is still a
> problem, though, because I expect a stale response for these
> subsequent requests before the origin responds.

Hmm, that's interesting. I agree that is a problem and I will have to
look into this further to see how it can be solved. If you have some
ideas or a patch I would be very interested in them.

>
> Thanks
>
> Kit
>
> On Wed, Sep 12, 2012 at 9:31 AM, Shu Kit Chan <ch...@gmail.com> wrote:
>> Hi,
>>
>> I am trying this plugin out
>> (https://github.com/apache/trafficserver/tree/master/plugins/experimental/rfc5861)
>> and I have a few concerns
>>
>> 1) Let's assume that my origin server becomes slow and takes 10
>> seconds to respond after a while. Initially the origin server response
>> is fast and cachable (e.g. "Cache-Control: max-age=30,
>> stale-while-revalidate=300, public") and a cached copy is in the ATS
>> cache. When the origin server becomes slow and the ATS cache copy
>> expires, I assume the plugin should be able to return stale response
>> from ATS and issue an async call to the origin server for the content.
>> It will continues to give out stale responses from all other requests
>> of this resource until the origin server comes back 10 seconds later
>> with the response and cached properly in ATS.
>>
>> However, I don't think the plugin is doing it this way. The async call
>> is made in a normal way and thus the cache URL is locked (according to
>> this diagram - http://trafficserver.apache.org/docs/trunk/sdk/http-hooks-and-transactions/index.en.html).
>> Subsequent requests to the same resource will get a cache miss and
>> will be blocked till the origin server comes back with a response 10
>> seconds later. So in reality, what happened is that once a resource is
>> expired, the first request for this resource will return with a stale
>> copy and all subsequent request for this resource will be blocked till
>> the origin server responds
>>
>> 2) Also, according to TS-998
>> (https://issues.apache.org/jira/browse/TS-998) , Wouldn't
>> TSHttpHdrPrint() be causing trouble for the rfc5861 plugin?
>> I can imagine that it will probably work when pristine_host_hdr is 0,
>> though. We might be able to construct the async request using
>> TSMimeHdrPrint() and construct the request line with previously saved
>> variables.
>>

This is not a problem because we use TSHttpHdrClone() in the
TS_HTTP_READ_REQUEST_HDR_HOOK before TS-998 bites us. This isn't ideal
because it makes a copy of every single request, but it is the only
work around I know of.

>> 3) "troot" is a variable used to remember what URL is being called
>> asynchronously right now. So a subsequent request to ATS will not
>> generate extra async call of the same URL. But URL is only part of
>> cache key. Some request headers can be part of the cache key based on
>> the "Vary" response header.
>>

Not sure I understand this case. We already did the cache lookup and
get back a STALE result so we want to do a fresh lookup to the origin
and don't have a 'Vary' response header to to account for. The intent of troot
isn't to lock the cache key, just the URL so we don't do multiple
requests. If I have missed some case here we can definitely make a
change to account for it.

>> Thanks.
>>
>> Kit

Thanks for the feedback. I'd like to get all the loose ends tied up and
see this plugin get some good usage.

Re: Questions on rfc5861/stale-while-revalidate experimental plugin

[Shu Kit Chan <ch...@gmail.com>]

Some updates for #1 after some more debugging.

I was wrong on cache URL being locked. There is no lock or connection
collapse yet. Those subsequent requests for the same resources are
just TCP_MISS, causing extra request to origin server. It is still a
problem, though, because I expect a stale response for these
subsequent requests before the origin responds.

Thanks

Kit

On Wed, Sep 12, 2012 at 9:31 AM, Shu Kit Chan <ch...@gmail.com> wrote:
> Hi,
>
> I am trying this plugin out
> (https://github.com/apache/trafficserver/tree/master/plugins/experimental/rfc5861)
> and I have a few concerns
>
> 1) Let's assume that my origin server becomes slow and takes 10
> seconds to respond after a while. Initially the origin server response
> is fast and cachable (e.g. "Cache-Control: max-age=30,
> stale-while-revalidate=300, public") and a cached copy is in the ATS
> cache. When the origin server becomes slow and the ATS cache copy
> expires, I assume the plugin should be able to return stale response
> from ATS and issue an async call to the origin server for the content.
> It will continues to give out stale responses from all other requests
> of this resource until the origin server comes back 10 seconds later
> with the response and cached properly in ATS.
>
> However, I don't think the plugin is doing it this way. The async call
> is made in a normal way and thus the cache URL is locked (according to
> this diagram - http://trafficserver.apache.org/docs/trunk/sdk/http-hooks-and-transactions/index.en.html).
> Subsequent requests to the same resource will get a cache miss and
> will be blocked till the origin server comes back with a response 10
> seconds later. So in reality, what happened is that once a resource is
> expired, the first request for this resource will return with a stale
> copy and all subsequent request for this resource will be blocked till
> the origin server responds
>
> 2) Also, according to TS-998
> (https://issues.apache.org/jira/browse/TS-998) , Wouldn't
> TSHttpHdrPrint() be causing trouble for the rfc5861 plugin?
> I can imagine that it will probably work when pristine_host_hdr is 0,
> though. We might be able to construct the async request using
> TSMimeHdrPrint() and construct the request line with previously saved
> variables.
>
> 3) "troot" is a variable used to remember what URL is being called
> asynchronously right now. So a subsequent request to ATS will not
> generate extra async call of the same URL. But URL is only part of
> cache key. Some request headers can be part of the cache key based on
> the "Vary" response header.
>
> Thanks.
>
> Kit