【问题标题】:Batching generation of http responses批量生成http响应
【发布时间】:2016-01-23 13:27:03
【问题描述】:

我正在尝试为以下场景寻找架构。我正在构建一个 REST 服务,该服务执行一些可以快速批量计算的计算。假设计算 1 个“项目”需要 50 毫秒,计算 100 个“项目”需要 60 毫秒。

但是,客户端的性质是一次只需要处理 1 个项目。因此,如果我有 100 个并发客户端,并且我编写发送一个项目并生成响应的典型请求处理程序,我最终将使用 5000 毫秒,但我知道我可以在 60 毫秒内计算出相同的值。

我正在尝试找到一种在这种情况下运行良好的架构。即,我希望有一些东西可以合并来自许多独立请求的数据,处理该批处理,并为每个单独的客户端生成等效的响应。

如果您好奇,有问题的服务是基于 python+django+DRF 的,但我很好奇这里适用什么样的架构解决方案/模式,以及是否已经有任何解决方案可用。

【问题讨论】:

  • 这不只是线程吗?如果计算不是那么快,我也会建议使用缓存

标签: performance rest http architecture


【解决方案1】:

首先,您可以考虑使用反向代理检测所有特定于模式的查询,收集所有这些查询并将其发送到 HTTP 1.1 管道 中的应用程序(管道是一种发送大数据的方法)一个接一个的查询数量,并在最后以相同的顺序接收所有 HTTP 响应,而无需在每个查询之后等待响应)。

但是:

  1. 流水线很难做好
  2. 您必须编写反向代理代码,因为我不知道怎么做
  3. 管道中的一个缓慢响应会阻塞所有其他响应
  4. 您需要一个能够为您的应用程序语言提供多个查询的 http 服务器,如果 http 服务器没有直接编码在您的应用程序中,则永远不会发生这种情况,因为通常 http 只处理一个查询(就像您从未收到PHP 环境中的 2 个查询,您收到第一个,发送响应,然后接收下一个,即使连接包含 2 个查询)。

所以在应用程序端这样做是个好主意。您可以识别匹配的查询,并等待一小段时间(10 毫秒?)以查看是否还有其他查询。您将需要一种方法在此处的多个并行工作人员之间进行通信(例如,您有 50 个应用程序工作人员,其中 10 个已收到可以在同一批次中处理的查询)。这种通信方式可以是数据库(一种非常快的)或一些共享内存,具体取决于所使用的技术。

然后,当等待时间过长(10 毫秒?)或收到大量查询时,其中一个工作人员可以收集所有查询,运行批处理,并告诉所有其他工作人员有结果(在这里,您再次需要一个通信中心点,例如 PostgreSQL 中的 LISTEN/NOTIFY、共享内存、消息队列服务等)。

最后,每个工作人员都有责任发送正确的 HTTP 响应。

这里的关键是有一个系统,您在尝试共享请求处理方面所花费的时间不如将多个查询批处理在一起所节省的时间重要,并且在这次流量低的情况应该保持合理(因为在这里你总是会浪费时间等待什么)。当然,您还会在系统上添加一些复杂性、更难维护等。

【讨论】:

  • 感谢您的想法...我一直在考虑使用消息队列而不是数据库或共享内存,因此请求处理程序可以等待响应。
猜你喜欢
  • 2015-05-07
  • 1970-01-01
  • 1970-01-01
  • 2020-12-10
  • 2013-03-03
  • 1970-01-01
  • 2010-09-29
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多