Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-enable the HTTP caching layer #55

Closed
GUI opened this issue Jul 10, 2014 · 1 comment
Closed

Re-enable the HTTP caching layer #55

GUI opened this issue Jul 10, 2014 · 1 comment
Assignees

Comments

@GUI
Copy link
Member

GUI commented Jul 10, 2014

The HTTP caching layer of api.data.gov is currently disabled. We need to get it re-enabed, but we need to validate some things first.

The caching layer got disabled when we encountered this bug with OPTIONS requests. We've worked around the issue on our end, and we've also got the underlying issue patched in NodeJS. However, while this was disabled, I discovered that some of our unrelated Varnish caching servers have been experiencing periodic failed requests due to this gzip+chunked responses+streaming issue in Varnish. The issue is very sporadic and seems to affect a very small percentage of requests, but it's still concerning, and I'd like to sort it out before re-enabling caching. I'm not 100% sure this same problem is happening on our api.data.gov servers, so that needs to be verified, but I suspect it might be if Varnish gets re-enabled (since we saw this issue on a few other different Varnish setups where streaming was enabled).

So before re-enabling caching:

  • Verify our workaround for the failed OPTIONS requests works for the fbopen team.
  • Try to come up with a test case to reproduce the sporadic issues seen when streaming is enabled in Varnish and the backend sends back chunked responses that are gzipped.
  • Assuming the same Varnish streaming issue is present in our stack, I believe the issue is somewhat inherit with Varnish 3 and streaming enabled with no known workarounds. In that case, we have a few options:
    • Disable streaming in Varnish: I'm pretty sure this fixes the problem, but then streaming is disabled, which I'd like to avoid (since I believe some users are dependent on it).
    • Upgrade to Varnish 4: Varnish 4 makes streaming the default (it was not in Varnish 3), so I'd assume this issue has been fixed in Varnish 4 (but more testing would be needed).
    • Switch the HTTP cache to Apache Traffic Server. I've started using this on another project and have been impressed. I've tested for the same gzip+streaming issues and haven't seen it. Some of Traffic Server's other features like it's clustering and persistent cache are also interesting. But it's doesn't seem quite as configurable as what Varnish allows with VCL, so we'd need to figure out how to handle things like Surrogate-Control headers.
@GUI
Copy link
Member Author

GUI commented Oct 13, 2014

Rolled out as part of #123

@GUI GUI closed this as completed Oct 13, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants