线程与异步图像处理？答案

【问题标题】：Threaded vs. asynchronous image processing?线程与异步图像处理？
【发布时间】：2011-01-30 17:02:32
【问题描述】：

我有一个 Python 函数，一旦访问它就会生成一个图像。我可以根据 HTTP 请求直接调用它，也可以使用 Gearman 异步调用它。 有很多请求。

哪种方式更好：

哪个选项更好？

在这种情况下，“更好”意味着最好的速度/负载组合。图像生成示例是象征性的，因为这也可以应用于数据库连接和其他事情。

【问题讨论】：

这取决于，生成 1 张图像需要多长时间？如果这个时间很短，您将在同一台机器上获得更好的结果处理。
“单独的工人”是指单独的进程还是单独的机器？处理是由 python 代码、本机编译的 python 模块还是其他东西完成的？这些问题的答案会影响您从各种选择中所期望的效率。
已更改。现在更有意义了。
我更新了我的答案，因为我相信我现在可以更好地回答你的问题？

【解决方案1】：

我有一个 Python 函数生成图像后访问。我可以调用它直接根据 HTTP 请求，或执行此操作异步使用 Gearman。那里有很多请求。

你不应该在你的请求中这样做，因为那样你就不能节流（你的服务器可能会过载）。所有大型站点都使用消息队列进行离线处理。

哪个选项更好？

在这种情况下，“更好”意味着最佳速度/负载组合。这图像生成示例是象征性的，因为这也可以是应用于数据库连接和其他的东西。

您应该异步执行此操作，因为除了加快您的网站速度之外，执行此操作的最令人信服的原因是，如果您处于高负载状态，您可以限制您的队列。您可以先执行优先级最高的任务。

我相信forking processes 很贵。我会创建几个工作进程（也许在进程内部做一些线程）来处理负载。我可能会使用redis，因为它是fast、actively developed（antirez/pietern 几乎每天都提交）并且有一个非常good/stable python client library。 blpop/rpush 可用于模拟队列（作业）

【讨论】：

【解决方案2】：

如果您的程序在解释器中受 CPU 限制，那么生成多个线程实际上会减慢结果，即使有足够的处理器来运行它们。这是因为 GIL（全局解释器锁）一次只允许一个线程在解释器中运行。

如果大部分工作发生在 C 库中，则很可能没有持有锁，您可以高效地使用多个线程。

如果您自己产生线程，则需要确保不要创建太多 - 10K 线程同时是个坏消息 - 因此您需要设置一个工作队列，线程从中读取而不是仅仅产生他们在一个循环中。

如果我这样做，我只会使用标准的多处理模块。

【讨论】：