tdp_org,
@tdp_org@mastodon.social avatar

I enabled Brotli compression on the CDN which serves the main BBC websites (www.bbc.co.uk. www.bbc.com etc.) outside the UK this morning.
Over ~4 hours, we're seeing a mean of ~20% better compression (smaller responses) via Brotli & ~95% of responses being Brotli now.
I've not had time to look in detail at performance but there doesn't look to be a significant change (LMK if you see diferent!).
(the spikes are breaking news events linking to a large "live" pages)

tdp_org,
@tdp_org@mastodon.social avatar

A little update on our enabling of Brotli for www.bbc.co.uk, www.bbc.com etc.
We're seeing compression improvements of roughly 15-40% over gzip. 15% is for HTML only, 40% is the overall. The caveat is that some clients which don't support Brotli request unusual content so this may be skewed to some degree.
I'll cover an issue which has cropped up in the next post.

tdp_org,
@tdp_org@mastodon.social avatar

Our stack is: Fastly -> GTM (BBC CDN) -> Belfrage (BBC routing) -> origins for most of our modern web pages.
Currently, only Fastly supports Brotli, the others do gzip, deflate & no compression.
Fastly strips gzip,deflate from the accept-encoding header sent to origin so our layers all return uncompressed content which means they're using more egress bandwidth. It's not a huge problem for us but something I thought might be useful for others to know.

markwalker,
@markwalker@fosstodon.org avatar

@tdp_org The stats are looking great. Need to see if we've got any games with a staging setup through fastly so I can have a dabble

slink,
@slink@fosstodon.org avatar

@tdp_org removing a-e: is a weird kink of fastly, but yeah, their fork point is ancient. with current filters, we can easily do "gunzip br".
thank you for the interesting update!

slink,
@slink@fosstodon.org avatar

@tdp_org nice!

i would also be interested in cpu metrics. also: which implementations are you using and which parameters to the compressor?

tdp_org,
@tdp_org@mastodon.social avatar

@slink Unfortunately I don't know any of that, sorry. This is on Fastly so it's all tied in to their platform.
I am planning on doing the same on our platform too though, once time allows. So at that point I can provide the info.

kura,
@kura@noc.social avatar

@tdp_org @slink any chance of pre-compressing the content at publish time and serving that as a static compressed asset? Then CPU won't matter at all. :D

tdp_org,
@tdp_org@mastodon.social avatar

@kura @slink Not sure on Fastly but I think nginx can do that - haven't looked in a while.
There's also the client CPU to consider too of course.

slink,
@slink@fosstodon.org avatar

@tdp_org @kura zstd also looks promising

slink,
@slink@fosstodon.org avatar

@kura @tdp_org this will need some coordination between your cdn and origin. a generic cdn will probably assume that your origin supports c-e: gzip only and create other encodings transparently. i have once implemented this in vcl for brotli, but it's not exactly trivial. https://gitlab.com/uplex/varnish/libvfp-brotli/-/blob/master/src/tests/realworld.vtc?ref_type=heads

ideally though, the cdn would also ask the origin for "br, gzip" and only do the recompression if the backend sent gzip.

gsuberland,
@gsuberland@chaos.social avatar

@tdp_org nice. server CPU usage over that time would be an interesting thing to plot, to see what the practical impact is. Brotli is a lot slower than gzip but if we're talking about a computation time of 5us going to 100us it's essentially noise compared to other load sources.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • webdev
  • ethstaker
  • DreamBathrooms
  • InstantRegret
  • magazineikmin
  • ngwrru68w68
  • cubers
  • thenastyranch
  • Youngstown
  • rosin
  • slotface
  • cisconetworking
  • mdbf
  • kavyap
  • Durango
  • megavids
  • khanakhh
  • GTA5RPClips
  • anitta
  • osvaldo12
  • everett
  • normalnudes
  • tester
  • tacticalgear
  • provamag3
  • modclub
  • Leos
  • JUstTest
  • lostlight
  • All magazines
    •