15

我有一个脚本,它使用 PHP 中的 curl_multi_* 函数运行 1000 个 cURL 请求。

他们超时背后的瓶颈是什么?

会不会是CPU使用率?就服务器如何处理该数量的出站连接而言,是否有更有效的方法来执行此操作?

我无法更改功能,请求本身就是对远程 API 的简单调用。我只是想知道限制是什么——我需要增加服务器上的内存、Apache 连接还是 CPU?(或者我错过的其他东西)

4

1 回答 1

14

您的请求是在单个执行线程中发出的。瓶颈几乎肯定是 CPU,你有没有看过 curl 多代码运行?... 令人难以置信的 CPU 饥饿;因为您对处理请求没有足够的控制权。curl_multi 使您可以一次编排 1000 个请求,但这并不是一个好主意。您几乎没有机会有效地使用 curl_multi,因为您无法足够精细地控制执行流程,仅服务套接字并在它们上选择()将导致您看到代码运行时看到的大量高 CPU 使用率命令行。

在此类任务期间CPU使用率很高的原因是这样的;PHP 被设计为运行几分之一秒,尽可能快地完成所有事情。CPU的使用方式通常并不重要,因为它的时间太短了。当你延长这样的任务时,问题变得更加明显,每个操作码所产生的开销对程序员来说都是可见的。

我知道你说过你不能改变实现,但仍然需要一个完整的答案。这样的任务比 curl multi 更适合 Threading,你应该开始阅读http://php.net/pthreads,从http://php.net/Thread开始

在空闲 CPU 上留给自己的设备,即使 1000 个线程也会消耗与 curl_multi 一样多的 CPU,关键是您可以精确控制负责下载响应的每个字节并上传请求的每个字节的代码,如果 CPU 使用率是您可以通过显式调用 usleep 或以有意义的方式限制连接使用来实现“好”过程,此外,您的请求可以在单独的线程中提供服务。

我不建议 1000 个线程是要做的事情,它很可能不是。要做的事情是设计一个 Stackable(请参阅文档),其工作是以“良好”、有效的方式发出和服务请求,并设计工作人员池(请参阅 github/pecl 扩展源上的示例)来执行您的新设计的请求...

于 2012-12-14T05:39:26.307 回答