请求内容大小和请求持续时间之间有什么关系

如何解决请求内容大小和请求持续时间之间有什么关系

在我工作的公司中，我们所有的API都会发送并期望遵循JSON:API standard的请求/响应，从而使请求/响应内容的结构非常规则。

由于这种规律性以及我们可以在一个请求中包含数百或数千条记录的事实，我认为这是相当可行的并且值得开始支持压缩的请求（每条记录的大小大约为

要对此操作的可行性进行充分的判断，我将不得不进一步了解请求大小和持续时间之间的关系，但是我在此方面找不到任何好的资源。有人愿意分享他们的专业知识/资源吗？

奖励1：如果您遇到请求性能问题，您会首先考虑将压缩作为解决方案吗？

红利2：传输开销如何随大小缩放？ （如果将尺寸减少50％，传输开销将减少多少百分比？）

解决方法

请求和响应压缩会增加发送方和接收方的时间和CPU负担。节省时间是在传输中。

权衡的权重很大程度上取决于API的客户-他们提出请求时，他们请求多少，所请求的内容，它们的位置，设备/操作系统和功能的类型等，

如果数据是静态的，例如：REST查询apihost / resource / idxx返回静态资源，则存在Web标准方法，例如缓存静态资源，客户端/代理将可以提供帮助。

如果数据是动态的，则可以使用某些架构模式。

如果数据量很大，例如：大型科学数据集，视频等，几乎总是会发现它们是由提供动态层的元数据服务静态提供的。例如：MPEG-DASH或HLS只是文件的集合。

相对于其他架构选项，我将选择压缩作为最后一个选项。

在执行请求/响应压缩之前，还有一些实现优化。例如：

• 您的服务是否使用了所有可用资源（核心，内存，I / O）
• 该体系结构是否允许扩展和扩展，并且可以使用该结构有效地解决问题（记住压缩带来的客户端损失）
• 您可以使用排队，缓存或其他机制使事情看起来更快吗？

如果您已经探索了所有这些问题，那么答案是您的系统是最佳的，并且您正在寻找的是最细粒度的服务单元，在这种情况下，数据量是一个问题，因此一定要进行压缩。请记住，您还需要预算用于服务器端压缩的计算资源（对于固定的工作量）。

关于传输开销与大小的问题＃2是有关带宽和延迟的问题。带宽决定了您可以推动多少。延迟控制感知的响应时间。无论有效负载是10字节还是10MB，相对于仅遇到一跳或两跳的客户端，世界范围内遇到多跳的客户端的延迟都会更大，并且受往返时间的限制。因此，一种解决方案可能是分发服务器并将其放置在世界各地更靠近您的客户端的位置，而不是压缩数据。这就是为什么压缩不是最先关注的另一个原因。

为有代表性的用户群建立性能基准并进行基准测试。

,

我认为您要权衡的是处理器/ CPU的速度与网络连接的速度。

网络连接会受到距离，信号强度，DNS提供商等因素的影响；但是，您的计算机硬件仅受其投入的功率的限制。

我敢打赌，在发送之前压缩数据会缩短响应时间，是的，但是可能很小。如果您要发送json，通常文本的开头并不是那么大，因此您可能只会看到毫秒级的性能变化。

如果这就是您想要的，我将继续实施它，在前后设置一些时间，然后检查您的结果。