问题 Http性能 - 许多小请求或一个大请求


场景:

  1. 在我的网站上,我展示了书籍。
  2. 用户可以将每本书添加到“稍后阅读”列表中。

行为:

当用户进入该站点时,将向他们显示书籍列表。 其中一些已经在他们的“Read Later”列表中,有些则不是。

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

我的问题

我在辩论哪种选择对我的情况是理想的。

选项1:

  1. 对于每本书,查询服务器是否已存在于用户列表中。
  2. 更新每本书的指标。

优点: 对服务器的请求非常小,响应非常简单(真或假)。

缺点: 在包含30本书的页面中,我将发送30个单独的http请求,这些请求可以阻止套接字,并且考虑到浏览器和服务器必须为每个事务执行整个握手,这个请求相当慢。

选项2:

  1. 我查询服务器一次,并获得一个响应,其中包含“Read Later”列表中的完整书籍列表作为数组。
  2. 在浏览器中,我查看了数组,并根据它是否存在于数组中来更新每本书的指示。

优点: 我只提出一个请求,并立即更新所有书籍的指标。

缺点: “稍后阅读”列表可能有数百本书,传递一个大数组可能会证明是缓慢而过度的。特别是在屏幕上没有出现30本书的情况下,只有2-3本。 (也就是说,我想检查某个书是否在列表中,为此我让服务器从列表中向客户端发送整个书籍列表)。

所以,

你会采用哪种方式来最大限度地提高性能:1还是2?

我有什么替代品吗?


6774
2018-04-29 04:31


起源

我认为问题是“意见答案”的边界,但我真的很感激明确的措辞和问题描述。 - GhostCat
感谢您的投入,我相信这是一个与许多主题相关的有用问题。一个大请求与许多小请求的问题。我真的相信它有一个明确的答案,或者至少有一些对我有帮助的好答案,还有SO的社区 - Michael Seltenreich
我投票决定将这个问题视为偏离主题,因为它询问广泛的设计问题,而不是关于编程。 - AdrianHHH
@AdrianHHH你在哪里建议我发布它?超级用户? - Michael Seltenreich
问题是:并非所有有趣/相关的问题都符合本网站的范围。但这并不一定意味着还有其他/更好的地方可以提出。 - GhostCat


答案:


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

选项2减轻了这种可扩展性问题,我们可以改进其设计:

客户端,通过javascript,只收集显示的书ID,并通过ajax查询一次读取后续信息,仅适用于那30本书。这样,您仍然可以快速提供页面并请求一小组附加信息,一次只需一个http请求。

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


1
2018-04-29 07:40



这听起来对我来说是对的!感谢您的投入! - Michael Seltenreich


我认为2017年的解决方案不仅关乎整体性能,还关乎用户体验和用户期望。

而现在用户不能容忍延迟。从这个意义上讲,复杂的用户界面尽可能快地响应。因此:如果你可以使用那些小的请求来让用户做某事(而不是等待一个大的请求返回2秒),你应该更喜欢这个解决方案。

据我所知,有很多“高保真”网站,有一个页面可能会发送50个,100个请求......所以我会考虑这种常见做法。

也许它在这里很有用:se-radio.net第277集在尾部延迟的背景下深入讨论了这个主题。


8
2018-04-29 04:42





在我看来,这取决于数据的存储方式。如果正在使用关系数据库,只需在相应的表上进行连接,就可以轻松地将布尔标记放入书籍列表中。 这很可能会给你最好的结果,你不必在前端编写任何算法。


2
2018-04-29 04:48



我想你错过了我的问题。查询数据没有问题,但是关于将数据从服务器传输到最终用户。 - Michael Seltenreich
我认为他的观点是,如果在后端快速查询30本书,那么在单个请求中没有任何内容可以反对包含所有这些内容的http调用 - Marged
30不是问题,300是。或者可能不是? - Michael Seltenreich
“这两个集合(显示和阅读书籍)的交集中的这个id”对关系数据库来说真的不是问题。如果您添加分页并且一次只显示大约30本书,您几乎看不出有什么区别。引入@MicheleP建议的一些聪明的chaching机制应该让你在可伸缩性方面做好准备。 - DaSourcerer