我有一个脚本，它使用 PHP 中的 curl_multi_* 函数运行 1000 个 cURL 请求。
它们超时的瓶颈是什么？
会是 CPU 使用率吗？就服务器如何处理该数量的出站连接而言，是否有更有效的方法来执行此操作？
我无法更改功能，请求本身只是对远程 API 的简单调用。我只是想知道限制是什么——我需要增加服务器上的内存、Apache 连接还是 CPU？ （或者我错过的其他东西）
【问题讨论】：
ulimit -a，这是您的限额）。除此之外，瓶颈可能成为网络。我怀疑 CPU 会不会死的......
您的请求是在单个执行线程中发出的。瓶颈几乎肯定是 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 扩展源上的示例）来执行您的新设计的请求...
【讨论】：