How is message compression handled in ws.publish?

[lahsuk]

Is it compressed only once or every time for each ws connection?

[uNetworkingAB]

It's a very good question. Old (v19) versions used to have a special path for shared compressor where it compressed once. The idea was that, clearly it must be best.

Problem is that it becomes complex when you have a mix of configurations but most importantly -

Shared compression sucks. It really sucks. Performance cost of compressing a message is inversely proportional to how similar the new message is, from the history of previously compressed messages. Also the ratio of compression is better the more similar the new message is.

With shared compression you essentially have 0 history and thus 0 similarity meaning maximum compression cost (CPU) and worst compression ratio. The performance cost of compresing a similar message is very small, while the cost of compressing a dissimilar message is so grand that it takes 90% of all overhead.

It turned out that nobody seriously used shared compression but really only used a dedicated compressor per connection.

So this "optimization" with a shared compressor was removed and the pub/sub simplified.

Compression really is a duct tape kind of solution to a problem that could have been solved with a minimal protocol, but bloated JSON is standard in web, so we have to deal with it. And people tend to deal with it by enabling per-socket compressors.

[uNetworkingAB]

Btw, there are forks of zlib that employ explicit SIMD instructions but I have benchmarked those and they don't really perform any better than regular zlib when the message is dissimilar. They do perform better than zlib when the message is similar. Because compressing a similar message is really just a lookup of backreferences. So again, the entire industry is built on the assumption that messages will be very similar, which they often are since they send the same JSON keys in every message. It's depressing but that's how web works.