Good Point Aymeric, it will probably not always be a good idea. I would require some kind of configuration to define which response content-type should be encoded by which algorithm. It might also be interesting if you could use pre-compressed full page caching. Which I think does currently not work. This could however be a good way to reduce CPU time.
Curtis also makes a good point on what kind of configraution should be supported by such a middlware. Best -Joe On Friday, September 14, 2018 at 12:25:12 PM UTC+2, Aymeric Augustin wrote: > > Hello, > > I would like to be sure that Brotli is actually faster. In my experience, > while decompression is fast, compression can be extremely slow. > > This is fine for static assets compressed by a build pipeline or at least > when the compressed version is cached. It would be a problem for on-the-fly > compression of dynamic content, which is what we're talking about here. > > I expect there's a setting for trading off compression time vs. > compression ratio. It should be set appropriately. It isn't worth spending > a lot more CPU to save a tiny bit of data transfer. The result could be > slower, especially for users with fast connections. > > I would like to see a quick performance benchmark of gzip as currently > implemented in Django vs. brotli with a setting you recommend, to see the > effect on compression time (CPU use) and compression ratio. > > Best regards, > > -- > Aymeric. > > Le ven. 14 sept. 2018 à 10:01, Johannes Hoppe <in...@johanneshoppe.com > <javascript:>> a écrit : > >> Hi there, >> >> we all know the the wonderful GZip middleware that allows response >> compression. Which is great especially if you are serving large responses. >> >> Now gzip is only one of many supported encoding types supported by many >> browsers. The coolest kid on the block seems to be brotli right now. >> It is both faster and smaller in most cases then gzip and has been >> standardized in https://www.ietf.org/rfc/rfc7932.txt >> >> Of course there is already a package that adds brotli support to Django: >> https://pypi.org/project/django-brotli/ >> >> But I would propose to refactor the GZip middleware into something like >> "CompressionMiddlware" and add support for both GZip and Brotli >> in the same middleware. >> >> I have the feeling something basing like response encoding should be >> build into Django. Of course I would not add a hard dependency to brotli, >> but add all methods to `Accept-Encoding` that are actually installed. >> >> What do you guys think? Is this worth a little refactoring? >> >> Best >> -Joe >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> Visit this group at https://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/29cf5142-fa82-4d74-9d8f-5fb0c8be34d0%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/29cf5142-fa82-4d74-9d8f-5fb0c8be34d0%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Aymeric. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3e7c5b75-fb08-40f1-9394-97fcd33ff6d3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
