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

【问题标题】：How to enable the compression option in a REST service如何在 REST 服务中启用压缩选项
【发布时间】：2014-12-04 13:59:23
【问题描述】：

我正在使用 rest-easy 框架开发 REST 服务。我的数据很大，而且是 application/json 格式。

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

但我发现客户端的时差没有差异。不管有没有@GZIP注解，响应时间都是一样的。

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

在将响应发送回客户端时，我还需要做些什么来实现压缩吗？

【问题讨论】：

您不会寻找时差，您会寻找尺寸差异。在 Chrome 的网络选项卡（开发人员工具）中，您将看到一个大小列，顶部的数字是传输大小，底部的数字是实际大小（未压缩）。 developers.google.com/web/fundamentals/performance/…
我压缩数据的全部原因，以便客户端可以更快地接收。我在这里错过了什么吗。这是否意味着只有压缩会减少通过网络传输的大小，但由于客户端需要解压缩，所以总时间将保持不变。我不知何故觉得很奇怪。我认为压缩是为了让响应更快。
通常它应该更快，因为您应该在接收较少量的数据时节省更多时间，然后您会在解压缩时放松。但这取决于数据的种类和数量以及客户端的能力。但是你没有回答pherris的问题：转账和实际大小有区别吗？
@pherris 是的，当我使用 chrome 测试我的服务时，大小和时间会有所不同。但是当我使用球衣客户端时，时间保持不变，我仍然在想为什么我需要设置客户端标头来请求压缩响应？

标签： json web-services rest resteasy

【解决方案1】：

下载文件的内容是什么？

Chrome 网络工具中的时间不仅仅是下载文件 - 如果您将鼠标悬停在“网络”选项卡的“时间轴”列中的块上，您会看到类似于下图的内容。这表明在所花费的 1.32 秒中，只有大约 70 毫秒是内容下载：

Holy 抽 1.05 秒进行 DNS 查找？！一定是我的VPN。请注意，TTFB（第一个字节的时间）是您的服务器开始响应所用的时间。

您应该节省多少时间？

要记住的另一件事是，您不会用 GZIP 节省很多时间（我刚刚因为这句话而失去了为 Google 工作的机会！）。 200 kb 和 100 kb 之间的下载时间在 5 mbps 连接下不到一秒（这几天相当慢）。

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

以上图为例，我们看到计算出的时间与您在“现实世界”中看到的不完全一样，因为在交换文件时还会发生其他事情（服务器带宽、网络异常等））。上图中的文件是 32.9 kb，0.2632 兆位，应该需要 52.64 毫秒，但实际上需要 70.437，但已经接近。随意纠正我的数学，我确定某处有错误；）

服务器时间呢？

最后，您可能想要查看生成文件所花费的时间 - 如果您的服务器需要 5 秒来生成文件，而在 5 mbps 连接上传输需要 800 毫秒，您可能可以使用 GZIP（最多可能 400 毫秒）不会尽可能多地改进事情，因此您的总时间仍将高达 5.4 秒，真正的问题是服务器生成文件所花费的时间。

【讨论】：

感谢@pherris，我更改了客户端以将编码作为 gzip.deflate 发送，我可以看到一些改进。但正如你所指出的，它没有我预期的那么多。使用 Gzip 压缩和解压缩的时间消耗了大部分时间。如果我使用其他一些压缩方法，我能做得更好吗，我需要做什么？我应该尝试哪个其他选项？
您的文件有多大（压缩/未压缩）？你几点了（你想看什么）？你是什么类型的连接？如果没有充分的理由，我会犹豫选择 GZIP 之外的另一条路线。

【解决方案2】：

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

【讨论】：

是的，我提到了这个过程，但我的问题是为什么客户端没有更快地接收数据？