Page MenuHomePhabricator

Enable HTTP compression for arclamp trace logs
Closed, DeclinedPublic

Description

Following from change 768116 to the coverme tool, I was enabling http compression for the downloads from integration.wikimedia.org and performance.wikimedia.org, but noticed that for the latter, the response did not support compression.

Afaik these domains are both backed by local Apaches and served through Varnish frontend and an ATS director on the backend.

A couple of hunches:

  • Something is preventing ATS or Varnish from compressing it on the fly.
  • Or, something is stripping Content-Encoding: deflate, gzip and not passing it on. (I know we do this for the bulk of our traffic so as to not have double the cache entries w.r.t Vary, and offload encoding away from MW appservers to edges in a streamed fashion; However we then also enable it on the edge; Perhaps the "perf" domain is getting one of these treatments but not the other?)
  • And/Or, the webperf apache is not configured to allow it.

These files can be several GB large, so it definitely seems worth serving with compression. On the other hand, I can also see how maybe this can become intensive. Maybe it's above a treshold where we perhaps (reasonably) decide not to do this on-the-fly. In which case we then have to decide whether that's an appropiate/needed mitigation for webperf specifically as well.

Event Timeline

Note that the coverme tool only consumes the latest files. I'm aware we have since turned on offline compression for the files themselves once they are no longer the files for today/yesterday.

Krinkle triaged this task as Medium priority.
Aklapper added a subscriber: dpifke.

Removing inactive task assignee (please do so as part of offboarding processes).