何时使用websockets perMessageDeflate？

Question

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

假设我有1000条消息（文本字符串的长度），每秒发送10次（每100毫秒），是否值得它压缩？

我听说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