请求内容大小和请求时长有什么关系
What is the relationship between request content size and request duration
在我工作的公司，我们所有的 API 都发送和期望 requests/responses 遵循 JSON:API standard，使得 request/response 内容的结构非常规则。
由于这种规律性以及我们可以在一个请求中拥有成百上千条记录这一事实，我认为开始支持压缩请求是相当可行且值得的（每条记录大约 < 50%它的 JSON:API 对应物的大小）。
为了对这个实际值得的可行性做出明智的判断，我必须更多地了解请求大小和持续时间之间的关系，但我找不到任何好的资源。有人愿意分享他们的 expertise/resources 吗？
奖励 1：如果您遇到请求性能问题，您会首先、其次还是最后考虑压缩作为解决方案吗？
奖励 2：传输开销如何随大小变化？ （如果我将大小减少 50%，传输开销将减少多少百分比？）
我认为您在这里权衡的是处理器的速度/cpu 与网络连接的速度。
网络连接可能会受到距离、信号强度、DNS 提供商等因素的影响；然而，您的计算机硬件仅受您投入的电量的限制。
我敢打赌，在发送之前压缩数据会缩短响应时间，是的，但这=可能会非常小。如果您要发送 json，通常开始时文本不会那么大，因此您可能只会看到毫秒级别的性能变化。
如果这就是你要找的，我会继续实施它，在前后设置一些时间，然后检查你的结果。
请求和响应压缩会增加发送方和接收方的时间和 CPU 损失。时间的节省在于传输。
权衡取舍在很大程度上取决于 API 的客户 -- 他们提出请求的时间、请求的数量、请求的内容、所在位置、类型 device/os 和功能等，
如果数据是静态的——例如：REST 查询 apihost/resource/idxx 返回静态资源，则有 Web 标准方法，例如客户端/代理能够协助的静态资源缓存。
如果数据是动态的——可以使用架构模式。
如果数据很大——例如：大型科学数据集、视频等，您几乎总是会发现它们是通过提供动态层的元数据服务静态提供的。例如：MPEG-DASH 或 HLS 只是文件的集合。
相对于其他架构选项，我会选择压缩作为最后一个选项。
在使用 request/response 压缩之前还有实现优化。例如：
- 您的服务是否使用了所有可用资源（内核、内存、i/o）
- 该体系结构是否允许 scale-up 和 scale-out 并且可以使用它有效地处理问题（记住由于压缩而对客户端造成的惩罚）
- 你能使用队列、缓存或其他机制来让事情看起来更快吗？
如果您已经探索了所有这些并且答案是您的系统是最佳的并且您正在寻找数据量是一个问题的最细粒度的服务单元，那么一定要进行压缩。请记住，您还需要为服务器端的压缩预算计算资源（对于固定工作负载）。
关于传输开销与大小的问题 #2 是关于带宽和延迟的问题。带宽决定了您可以通过管道推动多少。延迟控制感知的响应时间。无论有效载荷是 10 字节还是 10MB，全球范围内遇到多跳的客户端的延迟相对于仅遇到一跳或两跳的客户端来说会更大，并且受到 round-trip 时间的限制。因此，一个解决方案可能是分布服务器并将它们放置在离世界各地的客户更近的地方，而不是压缩数据。这是压缩不是首先要考虑的另一个原因。
为具有代表性的用户群设定性能基准和基准测试。
在我工作的公司，我们所有的 API 都发送和期望 requests/responses 遵循 JSON:API standard，使得 request/response 内容的结构非常规则。
由于这种规律性以及我们可以在一个请求中拥有成百上千条记录这一事实，我认为开始支持压缩请求是相当可行且值得的（每条记录大约 < 50%它的 JSON:API 对应物的大小）。
为了对这个实际值得的可行性做出明智的判断，我必须更多地了解请求大小和持续时间之间的关系，但我找不到任何好的资源。有人愿意分享他们的 expertise/resources 吗？
奖励 1：如果您遇到请求性能问题，您会首先、其次还是最后考虑压缩作为解决方案吗？
奖励 2：传输开销如何随大小变化？ （如果我将大小减少 50%，传输开销将减少多少百分比？）
我认为您在这里权衡的是处理器的速度/cpu 与网络连接的速度。
网络连接可能会受到距离、信号强度、DNS 提供商等因素的影响；然而，您的计算机硬件仅受您投入的电量的限制。
我敢打赌，在发送之前压缩数据会缩短响应时间，是的，但这=可能会非常小。如果您要发送 json，通常开始时文本不会那么大，因此您可能只会看到毫秒级别的性能变化。
如果这就是你要找的，我会继续实施它，在前后设置一些时间，然后检查你的结果。
请求和响应压缩会增加发送方和接收方的时间和 CPU 损失。时间的节省在于传输。
权衡取舍在很大程度上取决于 API 的客户 -- 他们提出请求的时间、请求的数量、请求的内容、所在位置、类型 device/os 和功能等，
如果数据是静态的——例如：REST 查询 apihost/resource/idxx 返回静态资源，则有 Web 标准方法，例如客户端/代理能够协助的静态资源缓存。
如果数据是动态的——可以使用架构模式。
如果数据很大——例如：大型科学数据集、视频等，您几乎总是会发现它们是通过提供动态层的元数据服务静态提供的。例如：MPEG-DASH 或 HLS 只是文件的集合。
相对于其他架构选项，我会选择压缩作为最后一个选项。
在使用 request/response 压缩之前还有实现优化。例如：
- 您的服务是否使用了所有可用资源（内核、内存、i/o）
- 该体系结构是否允许 scale-up 和 scale-out 并且可以使用它有效地处理问题（记住由于压缩而对客户端造成的惩罚）
- 你能使用队列、缓存或其他机制来让事情看起来更快吗？
如果您已经探索了所有这些并且答案是您的系统是最佳的并且您正在寻找数据量是一个问题的最细粒度的服务单元，那么一定要进行压缩。请记住，您还需要为服务器端的压缩预算计算资源（对于固定工作负载）。
关于传输开销与大小的问题 #2 是关于带宽和延迟的问题。带宽决定了您可以通过管道推动多少。延迟控制感知的响应时间。无论有效载荷是 10 字节还是 10MB，全球范围内遇到多跳的客户端的延迟相对于仅遇到一跳或两跳的客户端来说会更大，并且受到 round-trip 时间的限制。因此，一个解决方案可能是分布服务器并将它们放置在离世界各地的客户更近的地方，而不是压缩数据。这是压缩不是首先要考虑的另一个原因。
为具有代表性的用户群设定性能基准和基准测试。