这个 20MB 的 json 响应性能怎么样？答案

【问题标题】：How about this 20MB json response performance?这个 20MB 的 json 响应性能怎么样？
【发布时间】：2018-11-03 02:57:32
【问题描述】：

我在 django 中构建了一个 API，它使用 PostgreSQL 和序列化器查询数据到 json。

现在，这个 API 内容长度是 3MB（我使用 gzip，实际大小是 20MB）响应时间大约花费了我 10~20 秒。

我想问一下，这样的表现是对的吗？有什么优化空间可以做吗？

【问题讨论】：

我们看不到您在做什么，因此根据您提供的少量信息，您有几个选择：1) 减少从您的服务器返回的数据量询问。 2) 将结果拆分为多个响应，这些响应不需要很长时间来压缩和传输。 3) 减少您返回的数据量。 4) 我有没有提到减少您返回的数据量？ :-)
如果需要 10-20 秒，这听起来更像是糟糕的 API 设计，但是我不知道你的用例，所以我不能确定。检查您是否可以执行 Ken 的任何建议。

【解决方案1】：

如果需要 10-20 秒，这听起来更像是糟糕的 API 设计，但是我不知道您的用例，所以我不能确定。

检查您是否可以执行 Ken 的任何建议。这里还有一些想法：

Pagination 是拆分数据的好方法 - 如果您的数据可以拆分为逻辑部分，DRF 有很多方法可以对查询集进行分页。
考虑到数据的大小，使用正确的 gzip 压缩级别可能是一个因素。阅读更多信息here
看看是否可以使用etag 选项，如果在两次连续调用 API 之间 API 响应没有改变，服务器会发送 304 Not Modified。 DRF does not support etags 开箱即用的 AFAIK，因此您必须找到 work-around。
既然您提到了“实时”数据，我假设存在一些时间数据流的概念。有一些有趣的方法可以将client caching + cursor based 分页组合起来，只发送您可以探索的“新数据”。这仅在满足两个先决条件时才有效：对 API 的更改本质上是增量的和临时的。

【讨论】：