Merge lp://staging/~ahasenack/landscape-client/297623-curl-compression into lp://staging/~landscape/landscape-client/trunk
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Jamu Kakar | ||||
Approved revision: | 284 | ||||
Merged at revision: | 312 | ||||
Proposed branch: | lp://staging/~ahasenack/landscape-client/297623-curl-compression | ||||
Merge into: | lp://staging/~landscape/landscape-client/trunk | ||||
Diff against target: |
84 lines (+15/-7) 2 files modified
landscape/lib/fetch.py (+1/-0) landscape/lib/tests/test_fetch.py (+14/-7) |
||||
To merge this branch: | bzr merge lp://staging/~ahasenack/landscape-client/297623-curl-compression | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Jamu Kakar (community) | Approve | ||
Thomas Herve (community) | Approve | ||
Review via email: mp+47029@code.staging.launchpad.net |
Description of the change
This branch adds a header to our curl requests saying we support gzip and deflate compression methods. If the server supports them too, then compression can be negotiated.
I don't have many great ideas for testing the effectiveness of this other than firing up two machines, point them to staging and compare the traffic generated by each one of them. One using this branch, and the other not.
We could also change the apache logging to show the compression ratio that was achieved.
If you don't have other ideas, I will go ahead with the above using LDS as a guinea pig.
That being said, I of course already built packages with this branch and pointed them at production and staging, and it worked.
Fine with me, +1.