You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by realpdm <gi...@git.apache.org> on 2017/02/21 21:13:39 UTC
[GitHub] trafficserver issue #1478: sscl is occasionally zero (formerly TS-2998)
GitHub user realpdm opened an issue:
https://github.com/apache/trafficserver/issues/1478
sscl is occasionally zero (formerly TS-2998)
Scott Beardsley originally reported in https://issues.apache.org/jira/browse/TS-2998
Running ATS 5.0 it looks like sscl in the extended2.log is occasionally zero even for cache misses and HTTP 200 reponses... Here is how I am finding these cases:
```
tail -f extended2.log|awk '$23~/TCP_MISS/&&$11~/200/&&$12~/^0/
print $10,$11,$12,$23,$7
21452 200 0 TCP_MISS http://search.example.com/search?p=pizza
```
You can see that pscl ($10) is non-zero but sscl ($12) is zero. Where is ats getting the content from if it isn't coming from the origin? Is this related to the value of the content-length header from the origin? Ideally we would want to see the raw number of bytes coming from the origin.
Then Sudheer Vinukonda suggested:
> Now that I think of it, this may be related to TS-3049. Scott, do you know if you are seeing this issue only for a spdy client connection or do you also see this for non-spdy clients? Now that we have the fix for TS-3049 available, it might also be interesting to see if the issue still occurs after the fix is deployed.
And Scott responded
I just tried 5.0.1_20 (Y! version) and this specific problem persists... I'm reasonably certain this is unrelated to SPDY because I see it on machines which only serve HTTP traffic.
There could be some content-length/chunked issue going on, not sure. I do see this across a few drastically different origins.
The rate at which it happens is as follows:
HTTPS-only traffic: 24.9%
HTTP-only traffic: 25.6%
I haven't been able to isolate it yet. I'll start disabling plugins to see if the problem is some strange interaction with my setup.
And Karthik added:
I'm using 4.2.x and I see that sscl is always 0 when gzip is enabled. When I disable gzipping of response, sscl is set correctly.
----
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] trafficserver issue #1478: sscl is occasionally zero (formerly TS-2998)
Posted by maskit <gi...@git.apache.org>.
Github user maskit commented on the issue:
https://github.com/apache/trafficserver/issues/1478
It seems use of transform plugins (e.g. gzip plugin) cause this issue.
I'm not sure why range requests matter here.
https://github.com/apache/trafficserver/blob/7.1.x/proxy/http/HttpSM.cc#L3292-L3306
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---