GZip 压缩是否值得使用 AMF
我们有一个使用 BlazeDS 的 Flex/Java 应用程序，并且我们正在研究减少服务器和客户端之间传递的有效负载的大小。
由于 AMF 是一种二进制格式并且应该相当紧凑，因此打开 GZip 压缩有什么好处吗？以前是否有人这样做过？您是否发现使用压缩有任何显着的收益？
更新
我刚刚执行了一个简单的测试，以确定如果我们启用 gzipping，我们可能期望什么样的压缩比。我刚刚捕获了一些文件中的 AMF 有效负载，并使用 Linux 命令行版本对它们进行了 gzip 压缩。我没有指定压缩级别，只是默认的“正常”。看来有效负载大小平均减少了 9%，有些有效负载甚至减少了 61%。任何人都可以看到此方法中的缺陷以及 HTTP gzipping 中可以使用什么级别的压缩？
We've got a Flex/Java application using BlazeDS and we're investigating reducing the size of the payloads being passed between our server and the client.
Since AMF is a binary format and supposed to be fairly compact, is there any benefit to turning on GZip compression? Has anyone else done this before and did you see any significant gains from using compression?
UPDATE
I just performed a simple test to determine what kind of compression ratios we might expect if we were to enable gzipping. I just captured the AMF payloads in some files and just gzipped them using the Linux command line version. I didn't specify the level of compression, just the default i.e. 'normal'. It appears that on average there is a 9% reduction in the payload size, with some payloads getting as much as 61%. Can anyone see a flaw in this method and what level of compression can be used in HTTP gzipping?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们最近将一些客户端-服务器通信从 SOAP 切换到 AMF，并且我们还比较了压缩的影响。我们专注于一项特定的服务，该服务会带来一些巨大的反响。这些是我们的结果，返回相同的数据（对于 SOAP 使用 xfire+aegis 进行序列化，对于 AMF 使用 BlazeDS 进行序列化）：
我们的结论是 gzipping 绝对值得。二进制 AMF 的压缩效果几乎与 XML (SOAP) 一样好。当然，您的里程可能会根据您返回的数据类型而有所不同。
We have recently switched some client-server communication from SOAP to AMF, and we also compared impact of compression. We focused on one particular service which returns some big responses. These were our results, returning the same data (serialized with xfire+aegis for SOAP, and BlazeDS for AMF):
Our conclusion is gzipping is definitely worth it. The binary AMF can be compressed almost as good as XML (SOAP). Of course your mileage may vary depending on the kind of data you are returning.
这取决于数据。如果您有大量高度结构化的数据，那么通常它只使用实际信息的一小部分。那么压缩就有意义了。
例如，如果一条记录的类别字段是 6 种可能性之一，则如果它被编码为 GUID，则可能需要 32 位，但您可以用 3 位来表示它。压缩将使这些模式变得非常频繁并减少它们。
与非重复字符串类似。
AMF 对小整数和重复字符串有一些优化，但不是真正的压缩。请参阅此讨论。
做一些基准测试并做出决定。
It depends on the data. If you have lots of highly structured data, then typically it uses only a fraction of the bits of actual information. Then compression will make sense.
e.g. a record with a category field which is one of 6 possibilities might take 32-bit if it is encoded as a GUID, but you can represent it with 3 bits. Compression will see these patterns as very frequent and reduce them.
Similar for non repeating strings.
AMF has some optimizations for small integers and repeating strings, but not really compression. See this discusion.
Do some benchmarks and decide.
您可以使用我的人口普查 RIA 基准来尝试打开和关闭 GZIP 如何更改传输大小。但正如其他人指出的那样，结果在很大程度上取决于数据。因此，用自己的数据进行自己的测试是最好的决定方法。
另请记住，GZIP 双方都有开销，因此有时这种开销是值得的（连接速度较慢），有时则不然。
You can experiment with how turning GZIP on and off changes transfer sizes using my Census RIA Benchmark. But as others have pointed out the results depend heavily on the data. So doing your own tests with your own data is the best way to decide.
Also keep in mind that there is overhead on both sides to GZIP so sometimes that overhead is worth it (slower connections) and sometimes it's not.