-
Notifications
You must be signed in to change notification settings - Fork 582
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
Auto compression for HTTP and use zstd #1039
Comments
Eventually something like this (at least gzip given that zlib which we already depend on, has gzip support) could be added but in what way is not decided (could be automatic like you propose, or just a helper layer, or completely separate). Automatic is kind of promoting inefficient use, as you could in many case pre-compress the file and store it compressed and uncompressed on disk and then serve it based on headers. Then you would have 0 cost server side. So making it in a way that promotes efficient use is key. |
Yes, of course, I had that an explicit method was needed, for example something like this: This method will make it possible not to use compression in Node.js, this will be very useful, over time |
if not zstd, brotli can be used too for certain file types. personally i see this more like a plugin / helper as it's dependent on variable things like
some considerations
refs |
I use a middleware like this: app.get('/example.js', serveFile('src/example.js'));
app.get('/public/:file', serveDir('public'));
|
I'm really looking forward to how this new feature can help me be more productive at work. |
I will describe my particular case, I need to export data from a database to CSV format via HTTP, the response is 70 MB of text, gzip stream compresses it to 14 MB, but it takes 2 minutes with 100% processor load, this is a performance disaster, so we really need the ability to compress in uWS |
Hey.
I think this topic has already been raised, but once again I want to describe how important it is for real performance.
Most HTTP responses need to be compressed, now this has to be done on the Node side, this is not effective, and Chrome already supports the new compression method zstd: https://chromestatus.com/feature/6186023867908096
Safari and Firefox also plan to implement it.
It is ideal for fast (faster than gzip) stream compression, but Node does not have normal zstd streaming libraries.
If uWS implements compression on its side and will check the client Accept-Encoding header, if its value contains
zstd
then compress zstd, if not thengzip
.This is something that will really speed up all existing servers that use uWS, thank you.
The text was updated successfully, but these errors were encountered: