如何在REST服务中启用压缩选项

我正在开发一个使用rest-easy框架的REST服务。我的数据非常庞大，它的应用程序/ json格式。如何在REST服务中启用压缩选项

我试着用@GZIP注释我的服务方法来启用压缩。

但我发现在客户端的时差没有什么区别。带或不带@GZIP注释的响应时间是相同的。

我发送一个HTTP请求，响应是JSON格式的对象列表。

在将响应发送回客户端时，还需要做什么才能实现压缩？

2014-12-04 Bankelaal

你不会寻找时差，你会寻找大小差异。在Chrome的网络选项卡（开发人员工具）中，您将看到一个大小栏，顶部数字是传输大小，底部数字是实际大小（未压缩）。 https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/optimize-encoding-and-transfer#text-compression-with-gzip – pherris 2014-12-04 14:46:04

我压缩数据的所有原因，以至于客户端可以收到更快。我在这里错过了什么。这是否意味着只有压缩才能减小通过网络传输的大小，但是由于客户端需要进行压缩，所以总体时间将保持不变。我以某种方式发现它很奇怪。我认为压缩是为了使响应更快。 – Bankelaal 2014-12-05 00:56:08

通常它应该更快，因为您应该在接收少量数据时节省更多时间，然后在解压缩时就会松动。但这取决于数据的种类和数量以及客户端的功能。但你没有回答帕里斯的问题：转移和实际大小是否有所不同？ – lefloh 2014-12-05 07:36:34

什么是下载文件？

Chrome网络工具中的时间不仅包括下载文件 - 如果将鼠标悬停在“网络”选项卡的“时间轴”列中的块上，您将看到如下图所示的内容。这表明，采取1.32秒，仅约70毫秒的内容下载：

Chrome's network tab

圣抽烟1.05秒的DNS查找？必须是我的VPN。请注意，TTFB（第一个字节的时间）是服务器开始响应所需的时间。

您应该节省多少时间？

另一件事要记住的是，你救不了是很多时间与GZIP（我只是失去了我的投篮，在为谷歌正与该声明！）。 200 kb和100 kb之间的下载时间少于1秒，连接速度为5 mbps（这些日子非常慢）。

200 kb是1,600,000位或1.6兆位，所以您正在查看的5兆位连接1.6/5 = 0.32（或320毫秒下载）。如果启用GZIP并将文件大小降低到120 kb，则可以下载0.96 megabits或192 ms，节省128 ms（可敬，但可能不在您想要的数量级上）。

以上面的图片为例，我们看到计算出来的时间并不完全在“真实世界”中看到，因为在交换文件时还有其他事情正在进行（服务器带宽，网络怪异等等）。上图中的文件为32.9 kb，0.2632兆字节，应该占用52.64毫秒，但实际占用了70.437，但接近。随时纠正我的数学，我相信有一个地方的错误;）

服务器时间呢？

最后，你可能要考虑采取的时间量产生文件 - 如果您的服务器正在5S生成它和800ms的上一个5 Mbps的连接来传输，你可能无法提高事情与GZIP一样多（可能最大为400 ms），因此您的总时间仍将高达5.4 s，真正的问题在于服务器生成文件的时间。

来源

2014-12-05 15:30:44 pherris

谢谢@pherris，我改变了我的客户端发送编码为gzip.deflate，我可以看到一些改进。但是，正如你指出的那样不如我预期的那样。使用Gzip压缩和解压缩的时间已经耗尽了大部分时间。如果我使用其他压缩方法，我可以做得更好吗？我需要做些什么？我应该尝试哪个选项？ – Bankelaal 2014-12-07 04:44:05

你的文件有多大（压缩/解压缩）？你什么时候得到什么（你想看什么）？你在什么类型的连接？没有一个很好的理由，我会毫不犹豫地去除GZIP之外的另一条路线。 – pherris 2014-12-07 17:31:24

您不需要做任何其他操作，使用@GZIP启用压缩。 http://docs.jboss.org/resteasy/docs/2.2.1.GA/userguide/html/gzip.html

来源

2014-12-04 17:52:21

是的，我提到了这个过程，但我的问题是为什么客户端不能更快地收到数据？ – Bankelaal 2014-12-05 00:57:00

如何在REST服务中启用压缩选项

回答

相关问题