Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native Gzip & Brotli compression #2927

Open
1 task done
robd003 opened this issue Mar 21, 2024 · 5 comments
Open
1 task done

Native Gzip & Brotli compression #2927

robd003 opened this issue Mar 21, 2024 · 5 comments

Comments

@robd003
Copy link
Contributor

robd003 commented Mar 21, 2024

Is there an existing issue for this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe.

When serving larger responses it would be faster to send a compressed response as long as the client supports it.

Describe the solution you'd like

When a response from Sanic is over a certain threshold (2kb for Brotli / 512 bytes - 1kb for Gzip) and the HTTP client's accept headers permit it choose either Brotli or Gzip to compress the response

Additional context

It would be great to do this natively in Sanic rather than having to rely on something like nginx

@Tronic
Copy link
Member

Tronic commented Mar 30, 2024

I am not against this but there are complications. First of all, the compression is not async but would need extra threads to avoid blocking the server. Brotli would need to be an additional (optional) dependency, while gzip is available in the standard library. Checking and doing this for every request also costs, possibly more than the gain (even just checking/setting the headers and of course the compression itself with slow CPU and fast network).

Ideally static data (files or other common responses) should be precompressed - I wrote my own static file handler to replace Sanic's for this (it also keeps all static files and their compressed versions in RAM - loaded and compressed at each server startup to avoid storing .br on disk, because a few megabytes of RAM "wasted" don't cost anything).

Dynamic data compression per request can also be useful for large JSON data and such, and if added as a feature in Sanic, and this of course should not be done in case apps or other facilities already do compression. Streaming responses would be difficult to support.

Both types of compression can also be handled very efficiently by a proxy such as Nginx or Caddy. At least the latter supports static file and dynamic compression in gzip, brotli and zstd formats with a simple config directive.

@ahopkins
Copy link
Member

Are you talking about dynamic content or precomputing static content?

@robd003
Copy link
Contributor Author

robd003 commented Apr 1, 2024

This was for dynamic content.

@Tronic any chance you published your pre-compressed static file handler? That would be really useful!

@dmckeone
Copy link

If it helps at all, there is an open issue in sanic-ext for this: sanic-org/sanic-ext#230

It includes example code for Sanic extension that tried to serve as a baseline, derived from older extensions out in the wild.

@robd003
Copy link
Contributor Author

robd003 commented Aug 24, 2024

Thanks!

Link to @dmckeone's extension: https://gist.github.com/dmckeone/b6d2160389640270eb24d4b0555a7768

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants