> On Mar 23, 2015, at 6:08 PM, Dzmitry Markovich > <dmarkov...@linkedin.com.INVALID> wrote: > > Hello ATS experts, > > Today it is very common that http data that goes to the wire is compressed. > And we think it is a time to standardize this process in ATS core, since it > is very common operation. > > Today multiple plugins running on the same tier (that operates with response > body) do not have enough flexibility to handle gzip/gunzip - and most of the > times simply every plugin do gzip/gunzip. This lead to the situation when we > do gzip/gunzip multiple times while we process the http response. This leads > to the bad CPU utilization and performance. > > Yes, there is gzip/gunzip logic in atscpp API - so plugins can simply use > those. But today's ATS architecture does not allow us to fully control the > order of hook callbacks for every plugin per request - it means there is no > non-hacky way to prevent multiple gzip/gunzip calls while processing the > request. And there is no way to do that with the assumption that plugins dnot > know about each other. > > > Here is our high level proposal, just to start the conversation going: > - Have gzip/gunzip logic landed on ATS core, so engineers can ask ATS (vi > config parameter) to take care about gzip/gunzip logic for them > 1. Only ATS know when the body arrived to first plugin - so ATS at this > point ungzip the body; > 2. Only ATS knows when body is processed by all plugins and should go over > the wire - so ATS at this point gzip the body if client supported it.
Moving gzip to the core seems a generally good idea. Probably in some extensible way such that we can add future compression encoding (I think Chrome has support for some better ones?). Now, I’m slightly confused, and/or concerned, that our plugins do not handle this well. I would have imagined that something doing gzip would not do so if the content comes back with Content-Encoding: gzip. So shouldn’t e.g. ESI detect if the gzip plugin has already done so? Is there a reason why a plugin *can’t* detect this? If not, we should fix the plugins regardless of this RFE, it seems like a broken behavior if a plugin can gzip something that’s already CE: gzip. Cheers, — Leif
