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

Auto compression for HTTP and use zstd #1039

Open
uasan opened this issue Mar 18, 2024 · 6 comments
Open

Auto compression for HTTP and use zstd #1039

uasan opened this issue Mar 18, 2024 · 6 comments

Comments

@uasan
Copy link

uasan commented Mar 18, 2024

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 then gzip.

This is something that will really speed up all existing servers that use uWS, thank you.

@uNetworkingAB
Copy link
Contributor

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.

@uasan
Copy link
Author

uasan commented Mar 20, 2024

Yes, of course, I had that an explicit method was needed, for example something like this:
response.isCompresed(true | false) by default there should be no compression.

This method will make it possible not to use compression in Node.js, this will be very useful, over time zstd can be added later

@joshxyzhimself
Copy link
Contributor

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

  • what files do u serve
  • how many cores do u use
  • how many servers do u use
  • if you'd serve from disk or from memory
  • if you'd focus on compression speed or compression ratio

some considerations

  • a helper function for serving static files might help, which got its own complexities too
  • if these helpers are to be made for nodejs, there's extra work for deno and bun too
  • at certain point you stop optimizing for this and just serve these static files from a proper cdn (like bunny.net which is hella cheap), and use uws where it excels the most which is dynamic http requests and websockets

refs

@e3dio
Copy link
Contributor

e3dio commented Jun 17, 2024

I use a middleware like this:

app.get('/example.js', serveFile('src/example.js'));

app.get('/public/:file', serveDir('public'));

serveFile sets up a file watcher, runs brotliCompress from node:zlib on any file changes, stores the raw bytes and compressed bytes in ram, serves correct file according to request headers and sets Etag header. Might publish that code along with some other helpers

@drag0n-app
Copy link

I'm really looking forward to how this new feature can help me be more productive at work.

@uasan
Copy link
Author

uasan commented Nov 24, 2024

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

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

No branches or pull requests

5 participants