Http Performance - 许多小请求或一个大请求

时间:2017-04-29 04:31:06

标签: performance http

情境:

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

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

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

    我的问题

    我在辩论哪种方案适合我的情况。

    选项1:

    1. 对于每本书,查询服务器是否已存在于用户列表中。
    2. 更新每本书的指标。
    3. 对服务器的请求非常小,响应非常简单(真或假)。

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

      选项2:

      1. 我查询服务器一次,并在“稍后阅读”列表中以完整的书籍列表作为数组获得回复。
      2. 在浏览器中,我查看了数组,并根据是否存在于数组中更新每本书的指示。
      3. 专业版:我只提出一个请求,并立即更新所有图书的指标。

        Con:“稍后读取”列表可能包含数百本书,传递大型数据可能会导致速度过慢。特别是在屏幕上没有出现30本书的情况下,只有2-3本。 (也就是说,我想检查某个书是否在列表中,为此我让服务器从列表中向客户端发送整个书籍列表。)

        因此,

        您将以哪种方式最大限度地提高效果:1还是2?

        我有什么替代品吗?

3 个答案:

答案 0 :(得分:12)

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

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

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

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

答案 1 :(得分:4)

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

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

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

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

答案 2 :(得分:2)

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