trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 3ill <jmo...@gmail.com>
Subject ATS returning cache hit on partially cached response
Date Thu, 28 Jul 2016 13:34:40 GMT
Hi,

I have come across a strange ATS behavior that I'm hoping someone can help
with.

My setup is as follows:

I have an origin server that exposes an end point that returns streaming
JSON data, the size of the data that is returned by this end point is
unknown at the point of receiving the HTTP request so the origin server
returns back the following headers (captured from a wget):

HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Vary: Accept-Encoding
  Cache-Control: max-age=345600
  Expires: Mon, 01 Aug 2016 14:21:10 GMT
  Date: Thu, 28 Jul 2016 14:21:10 GMT
  Access-Control-Allow-Origin: *
  Access-Control-Allow-Methods: PUT, GET, POST, DELETE, HEAD
  Content-Type: text/plain; charset=iso-8859-1
  Server: Jetty(6.1.26)
Length: unspecified [text/plain]

I have placed ATS (configured in reverse proxy mode, in a cluster config of
6 nodes) in front of my origin servers. The reason for doing this is the
json response from the origin server is immutable and cache-able and allows
me to offload a lot of pressure on my origin server/data store.

When I query the same request via ATS I see the below headers:
HTTP request sent, awaiting response...
  HTTP/1.0 200 OK
  Vary: Accept-Encoding
  Cache-Control: max-age=345600
  Expires: Mon, 01 Aug 2016 14:24:58 GMT
  Date: Thu, 28 Jul 2016 14:24:58 GMT
  Access-Control-Allow-Origin: *
  Access-Control-Allow-Methods: PUT, GET, POST, DELETE, HEAD
  Content-Type: text/plain; charset=iso-8859-1
  Server: ATS/5.3.2
  Age: 0
  Connection: close
  Via: http/1.1 cluster1 (ApacheTrafficServer/5.3.2 [uScMsSfWpSeN:t cCMi p
sS])
Length: unspecified [text/plain]

My problem is as follows:

Due to the size of the response that is returned it can take several seconds
for the complete response to be sent back to the client.

I have been able to recreate the issue easily using wget in two separate
terminal sessions.

In the first terminal session (Terminal 1), I do a wget (without setting any
accept-encoding request headers), I wait for the headers to come back and as
soon as they do, I do the same wget in the second terminal window (Terminal
2). After a few seconds, in the first terminal I get the full response back
from the wget call, below are the headers sent back to the client:

>From Terminal 1:
HTTP request sent, awaiting response...
  HTTP/1.0 200 OK
  Vary: Accept-Encoding
  Cache-Control: max-age=259200
  Expires: Sat, 30 Jul 2016 12:20:08 GMT
  Date: Wed, 27 Jul 2016 12:20:08 GMT
  Access-Control-Allow-Origin: *
  Access-Control-Allow-Methods: PUT, GET, POST, DELETE, HEAD
  Content-Type: text/plain; charset=iso-8859-1
  Server: ATS/5.3.2
  Age: 0
  Connection: close
  Via: http/1.1 cluster1 (ApacheTrafficServer/5.3.2 [uScMsSfWpSeN:t cCMi p
sS])
Length: unspecified [text/plain]

>From Terminal 2 however, I never get the full response back, the call
ultimately times out after 10mins:

Below are the headers from the call in Terminal 2:
HTTP request sent, awaiting response...
  HTTP/1.0 200 OK
  Vary: Accept-Encoding
  Cache-Control: max-age=259200
  Expires: Sat, 30 Jul 2016 12:20:08 GMT
  Date: Wed, 27 Jul 2016 12:20:08 GMT
  Access-Control-Allow-Origin: *
  Access-Control-Allow-Methods: PUT, GET, POST, DELETE, HEAD
  Content-Type: text/plain; charset=iso-8859-1
  Server: ATS/5.3.2
  Age: 1
  Connection: close
  Via: http/1.1 cluster1 (ApacheTrafficServer/5.3.2 [uScHs f p eN:t cCHi p s
])
Length: unspecified [text/plain]

The interesting thing to highlight here is that the response I get back from
the call in Terminal 1 is a cache miss (as expected) however, the response I
get back from Terminal 2 is a cache hit. However, ATS has not completed
stored the entire object in its cache since its still streaming it back to
the client.

Another interesting thing to point out is if I do the same experiment but
explicitly specifying "accept-encoding: gzip" in the wget call I am able to
get the full response back from both calls with no timeout issues at all.
Why does ATS behave differently in this scenario when a client requests gzip
encoding vs no encoding at all? 

Below are the headers I get back from Terminal 1 when sending
"accept-encoding: gzip":
HTTP request sent, awaiting response...
  HTTP/1.0 200 OK
  Vary: Accept-Encoding
  Cache-Control: max-age=259200
  Expires: Sun, 31 Jul 2016 14:39:06 GMT
  Date: Thu, 28 Jul 2016 14:39:06 GMT
  Access-Control-Allow-Origin: *
  Access-Control-Allow-Methods: PUT, GET, POST, DELETE, HEAD
  Content-Type: text/plain
  Content-Encoding: gzip
  Server: ATS/5.3.2
  Age: 2
  Connection: close
  Via: http/1.1 cluster1 (ApacheTrafficServer/5.3.2 [uScMsSfWpSeN:t cCMi p
sS])
Length: unspecified [text/plain]

Below are the headers I get back from Terminal 2 when sending
"accept-encoding: gzip":
HTTP request sent, awaiting response...
  HTTP/1.0 200 OK
  Vary: Accept-Encoding
  Cache-Control: max-age=259200
  Expires: Sun, 31 Jul 2016 14:39:09 GMT
  Date: Thu, 28 Jul 2016 14:39:09 GMT
  Access-Control-Allow-Origin: *
  Access-Control-Allow-Methods: PUT, GET, POST, DELETE, HEAD
  Content-Type: text/plain
  Content-Encoding: gzip
  Server: ATS/5.3.2
  Age: 0
  Connection: close
  Via: http/1.1 cluster1 (ApacheTrafficServer/5.3.2 [uScMsSf pSeN:t cCMi p
sS])
Length: unspecified [text/plain]

Can someone please shed some light on this issue?

Thanks.



--
View this message in context: http://apache-traffic-server.24303.n7.nabble.com/ATS-returning-cache-hit-on-partially-cached-response-tp2554.html
Sent from the Apache Traffic Server mailing list archive at Nabble.com.

Mime
View raw message