Simultaneous Requests For Same Object

[Jason Strongman <ja...@gmail.com>]

ATS 4.2.1

Simultaneous Requests For Same Object

Is there an ATS setting/configuration which will queue requests while the
initial request is being serviced by the origin ?

In recent testing I find requests for the same un-cached object(ranging
from 40k-800k), all coming within milliseconds of each other, results in
multiple connections/requests back to the origin.  So in my logs I find ,
MISS, MISS, MISS, MISS, MISS, etc, then eventually a HIT. Takes about 2-5
seconds for the HIT to eventually log..

Following the 'Reducing Origin Server Requests' guidelines doesn't seem to
limit the amount of connections/requests back to origin for the same object.

My guess is that no data has yet to be returned, only a GET has been sent
to the origin. So without the partial response there is nothing to 'read
while write'.  More pcap analysis is needed I suppose.

Ideally it would seem ATS would note the initial in-flight GET, then queue
the other requests until a response is received. If no response is received
after x amount of time, then the queued requests are allowed to be
processed as expected.

Thoughts?

Thanks!

Re: Simultaneous Requests For Same Object

[Ethan Lai <yz...@yahoo.com>]

Jason,

You may enable Read While Writer
<https://trafficserver.readthedocs.org/en/latest/admin/http-proxy-caching.en.html#reducing-origin-server-requests-avoiding-the-thundering-herd>
or
use collapsed_connection plugin
<https://issues.apache.org/jira/browse/TS-2604> (experimental)

Best,
-Ethan


2014-07-15 12:09 GMT+08:00 Jason Strongman <ja...@gmail.com>:

>
> ATS 4.2.1
>
> Simultaneous Requests For Same Object
>
> Is there an ATS setting/configuration which will queue requests while the
> initial request is being serviced by the origin ?
>
> In recent testing I find requests for the same un-cached object(ranging
> from 40k-800k), all coming within milliseconds of each other, results in
> multiple connections/requests back to the origin.  So in my logs I find ,
> MISS, MISS, MISS, MISS, MISS, etc, then eventually a HIT. Takes about 2-5
> seconds for the HIT to eventually log..
>
> Following the 'Reducing Origin Server Requests' guidelines doesn't seem to
> limit the amount of connections/requests back to origin for the same object.
>
> My guess is that no data has yet to be returned, only a GET has been sent
> to the origin. So without the partial response there is nothing to 'read
> while write'.  More pcap analysis is needed I suppose.
>
> Ideally it would seem ATS would note the initial in-flight GET, then queue
> the other requests until a response is received. If no response is received
> after x amount of time, then the queued requests are allowed to be
> processed as expected.
>
> Thoughts?
>
> Thanks!
>