什么时候使用websockets perMessageDeflate？

Question

我一直找不到关于perMessageDeflate选项/模块的有用性/实用性的好信息。

假设我有1000位(文本字符串的长度)的消息，每秒发送10次(每100ms)，压缩值得吗？

我听说perMessageDeflate在CPU使用率上是个怪物。我想，如果你的消息真的很小而且不频繁，那就不划算了。

不管怎样，有谁知道门槛是什么？在数据包大小和频率(即带宽)方面，使用perMessageDeflate是一种明智的想法吗？

Answer 1

很难获得规范的信息，但我想说，对于少于500字节的信息来说，这是没有意义的。

据我所知，只有Google Chrome支持WebSocket压缩。此外，如果客户端或服务器请求上下文接管，它也可以在没有“上下文接管”的情况下工作，因此总体压缩比更低(因为每条消息都使用新的上下文)。

当涉及到性能时，几乎所有事情都是如此:首先测量当前性能以获得基线，然后启用它，然后再次测量。

https://webmasters.stackexchange.com/questions/31750/what-is-recommended-minimum-object-size-for-gzip-performance-benefits

http://www.itworld.com/article/2693941/cloud-computing/why-it-doesn-t-make-sense-to-gzip-all-content-from-your-web-server.html