Currently none of the tbpl.mozilla.org requested are served gzipped. Both the static assets and the fairly hefty getRevisionBuilds.php responses (the latter being at least 10 calls of 50-200 KB each) would benefit significantly.

Enable gzip compression for everything other than images. Not fussed about older clients. Shyam, is the in-tree .htaccess the preferred way of doing this? :-)

Some sizeable gains, eg: * UserInterface.js... 57KB -> 15KB * getRevisionBuilds.php... 191KB -> 16KB

I've landed this because TBPL is unusable in it's current state for at least three of the sheriffs (and whilst this isn't the cause, it will at least counteract some of the slowdown): https://hg.mozilla.org/webtools/tbpl/rev/6b43f97d7d01 Shyam, I'd still be interested in your feedback as to whether this is the right approach - thank you :-)

https://tbpl.mozilla.org/ report: http://www.webpagetest.org/result/130805_DP_16JP/3/details/ { Bytes In: 813KB } https://tbpl-dev.allizom.org/ report (with gzip enabled): http://www.webpagetest.org/result/130805_JQ_174V/5/details/ { Bytes In: 292KB }

In production, but leaving bug open to confirm this is the preferred implementation.

(In reply to Ed Morley [:edmorley UTC+1] from comment #5) > In production, but leaving bug open to confirm this is the preferred > implementation. I'd defer to webops. I think Zeus does gzip too.

(In reply to Shyam Mani [:fox2mike] from comment #6) > (In reply to Ed Morley [:edmorley UTC+1] from comment #5) > > In production, but leaving bug open to confirm this is the preferred > > implementation. > > I'd defer to webops. I think Zeus does gzip too. Brandon, not sure who to ask from webops - are you the right person/do you know who might be? :-)

(In reply to Ed Morley [:edmorley UTC+1] from comment #7) > (In reply to Shyam Mani [:fox2mike] from comment #6) > > (In reply to Ed Morley [:edmorley UTC+1] from comment #5) > > > In production, but leaving bug open to confirm this is the preferred > > > implementation. > > > > I'd defer to webops. I think Zeus does gzip too. > > Brandon, not sure who to ask from webops - are you the right person/do you > know who might be? :-) File a bug in https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=WebOps%3A%20IT-Managed%20Tools and one of the folks managing that component can see what can be implemented in Zeus, as having Zeus do it will be faster We should also rope in OpSec to make sure that this is enabled in a way that doesn't expose a http://breachattack.com/ type vulnerability

Comment on attachment 784938 [details] [diff] [review] Patch v1 Review of attachment 784938 [details] [diff] [review]: ----------------------------------------------------------------- r- only because I'm not sure we should be doing this on the server itself. I'm a fan of off-loading this stuff to Zeus. Also, deferring to webops to figure out the correct solution here.

(In reply to Brandon Burton [:solarce] from comment #8) > File a bug in > https://bugzilla.mozilla.org/enter_bug. > cgi?product=Infrastructure%20%26%20Operations&component=WebOps%3A%20IT- > Managed%20Tools and one of the folks managing that component can see what > can be implemented in Zeus, as having Zeus do it will be faster Filed bug 920563. > We should also rope in OpSec to make sure that this is enabled in a way that > doesn't expose a http://breachattack.com/ type vulnerability Other than toggling visibility of jobs (which uses a hardcoded fixed password, currently stored in the whiteboard of bug 322423; for which malicious access will only be 'mildly irritating' rather than anything more), there are no other session tokens or secrets used by TBPL, so I don't believe this is an issue. Closing the bug since this is already in production (see comment 3 for why), bug 920563 can undo the work here once we've switched to Zeus. Thank you for the Zeus idea :-)

Backed out now that Zeus is hopefully handling gzip compression via bug 920563: https://hg.mozilla.org/webtools/tbpl/rev/f31bfe7d347d Will test on tbpl-dev and close this WONTFIX if all is working as expected.

Is looking fine :-)