我有一个脚本，它使用 PHP 中的 curl_multi_* 函数运行 1000 个 cURL 请求。
超时背后的瓶颈是什么？
会不会是 CPU 使用率？就服务器处理出站连接数的方式而言，是否有更有效的方法来做到这一点？
我无法更改功能，请求本身只是对远程 API 的简单调用。我只是想知道限制是什么——我是否需要增加服务器上的内存、Apache 连接或 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 扩展源上的示例)来执行您的新设计的请求...
关于php - 设置的最大cURL连接数是多少？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13850951/