【问题标题】:REST API - Batch processing vs mutiple callsREST API - 批处理与多次调用
【发布时间】:2018-11-07 21:17:48
【问题描述】:

我正在编写 API 以接受 POST 请求并提供输出。用例是,我应该能够支持单输入和输入。所以,我想出了一个这样的结构:

输入:

{
    "inputs": [{
            "id": 1,
            "foo": "bar"
        },
        {
            "id": 2,
            "foo": "baz"
        }
    ]
}

输出:

{
    "outputs": [{
            "id": 1,
            "result": "bax"
        },
        {
            "id": 2,
            "result": "bar"
        }
    ]
}

这种格式既支持单次调用,也支持多次调用。但是,这意味着 API 必须处理 CPU 和线程,例如一个 API 调用可能包含 100 个输入,处理这些可能需要一段时间。所以,我需要输入以下几点:

  • 如果 API 的职责只是处理输入,那么 CPU/线程处理是否应该在消费者级别完成并使用多个调用来处理多个输入? (即每次调用一个输入)
  • 如果我每次调用切换到一个输入,我最终可能会进行多次调用(可能使用不同的端点),这对于每次调用一个调用(假设是 100 个输入)是否有效(就网络流量而言)? (即对每个请求设置硬性限制)
  • 混合方法是个好主意吗?即处理一批 1000 个输入,我可以将其分成 100 个输入的小批量并进行 10 次调用
  • API 将使用 Python/R 编写,我对这些语言如何处理多线程没有太多了解。

如果这个问题更适合 Stack Exchange,那么我很高兴它被转移。

【问题讨论】:

  • 第二个问题,多次通话意味着网络上的多次时间浪费。会慢一些。
  • 我认为批处理要好得多。但是您需要构建一个结构来有效地同时处理多个任务。例如,创建一个进程池(由于 GIL,Python 中的线程不会使用多核。)并将任务提交到池中,当所有任务完成时,返回结果。
  • @Sraw 同意,这是关于多个调用的 CPU 时间与单个调用的网络延迟之间的权衡。
  • 似乎 API 设计必须更接近您的任务规范——如果您最初必须批量处理它——使其成为批量输入。网络约束通常比 CPU 使用时间更具约束力。
  • @EvgenyPogrebnyak 我想要这两种功能。尽管最初的用例是批处理的,但我希望能够使用相同的 API 进行最少的更改或没有更改。我应该对这两种方法进行基准测试吗?

标签: python r api batch-processing flask-restful


【解决方案1】:

设置您的网络服务器以接受 HTTP2 并使用可使用 HTTP2 多路复用的 HTTP2 感知库编写客户端调用。

谷歌顶部是https://hyper.readthedocs.io/en/latest/

这允许您在不进行批处理的情况下恢复到纯 REST,其中通过 HTTP2 连接多路复用减少了多次调用的网络影响 - 即只在客户端和服务器之间创建一个连接。

这取决于可维护性和性能之间的权衡。 HTTP2 将使您免去管理多个线程的麻烦。据推测,尽管与批处理相比,多次调用仍然会对网络产生影响,尤其是在批处理很大的情况下。

【讨论】:

    猜你喜欢
    • 2020-07-26
    • 1970-01-01
    • 2017-01-11
    • 1970-01-01
    • 2016-08-04
    • 1970-01-01
    • 2016-04-07
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多