Http 性能 - 许多小请求或一个大请求答案

【问题标题】：Http Performance - Many small requests or one big oneHttp 性能 - 许多小请求或一个大请求
【发布时间】：2017-04-29 04:31:06
【问题描述】：

场景：

行为：

当用户进入网站时，他们会看到一个书籍列表。其中一些已经在他们的“稍后阅读”列表中，有些则不在。

用户在每本书旁边都有一个指示，告诉他们该书是否已添加到列表中。

我的问题

我正在争论哪个选项最适合我的情况。

选项 1：

专业人士： 对服务器的请求非常小，响应非常简单（真或假）。

缺点：在一个包含 30 本书的页面中，我将发送 30 个单独的 http 请求，这会阻塞套接字，考虑到浏览器和服务器必须为每个请求执行整个握手，这相当慢交易。

选项 2：

专业人士：我只提出一个请求，一次更新所有书籍的指标。

缺点：“稍后阅读”列表可能包含数百本书，传递一个大数组可能会变得缓慢且过多。尤其是在屏幕上出现的不是 30 本书，而是只有 2-3 本书的情况下。（也就是说，我想检查某本书是否在列表中，为此我让服务器向客户端发送列表中的整个书籍列表）。

那么，

您会采用哪种方式来最大限度地提高性能：1 还是 2？

我还缺少其他选择吗？

【问题讨论】：

我认为这个问题接近于“意见答案”，但我非常感谢清晰的措辞和问题描述。
感谢您的意见，我相信这是一个与许多主题相关的有用问题。 1 个大请求与许多小请求的问题。我真的相信它有一个明确的答案，或者至少有几个对我有帮助的好答案，还有 SO 社区
我投票结束这个问题，因为它是关于广泛的设计问题而不是编程问题。
@AdrianHHH 你建议我把它贴在哪里？超级用户？
问题是：并非每个有趣/相关的问题都适合本网站的范围。但这并不一定意味着还有其他/更好的地方可以问。

【解决方案1】：

我认为，在 2017 年及以后，解决方案不再是整体性能，而是用户体验和用户期望。

现在用户不容忍延迟。从这个意义上说，复杂的用户界面试图尽快做出响应。因此：如果您可以使用这些小请求来使用户能够快速执行某项操作（而不是等待 2 秒让一个大请求返回），那么您应该更喜欢该解决方案。

据我所知，有许多“高保真”网站，其中一个页面可能会发送 50、100 个请求。所以我会考虑这种常见的做法。！

也许在这里会有所帮助：se-radio.net 播客episode 277 在尾部延迟的背景下深入讨论了这个话题。

【讨论】：

【解决方案2】：

选项 1 听起来不错，但在可扩展性方面存在很大问题。

选项 2 缓解了这个可扩展性问题，我们可以改进它的设计：

客户端通过 javascript 仅收集显示的图书 ID，并通过 ajax 查询一次，以获取一系列稍后阅读的信息，仅针对这 30 本书。这样，您仍然可以快速提供页面并请求一小组附加信息，只需一次 http 请求即可。

在服务器端，您可以进一步改进缓存每个用户的稍后读取 ID 的内存数组。

【讨论】：

【解决方案3】：

在我看来，这取决于数据的存储方式。如果正在使用关系数据库，您可以通过简单地对相应的表进行连接来轻松地将布尔标志添加到书籍列表中。这很可能会给你最好的结果，而且你不必在前端编写任何算法。

【讨论】：

我想你误解了我的问题。我没有查询数据的问题，而是将其从服务器传输到最终用户。
我认为他的观点是，如果后端对 30 本书的查询速度很快，那么没有什么可以反对在一个请求中包含所有这些书的 http 调用
30 不是问题，300 是。或者不是？
“这个 id 是否在这两组的交集（正在显示和阅读书籍）”对于关系数据库来说确实不是问题。如果您添加分页并且一次只显示大约 30 本书，您应该几乎看不出有什么不同。按照@MicheleP 的建议，引入一些巧妙的 chaching 机制应该让您在可扩展性方面做好准备。