リクエストは単一の実行スレッドで行われます。ボトルネックはほぼ間違いなく CPU ですが、curl マルチコードの実行を実際に見たことがありますか? ... 信じられないほど CPU を消費しています。リクエストの処理を十分に制御できないためです。curl_multi を使用すると、一度に 1000 個のリクエストを調整できますが、これは良い考えではありません。実行フローを十分に細かく制御できないため、curl_multi を効率的に使用する可能性はほとんどありません。ソケットにサービスを提供し、ソケットで select() を実行するだけで、コードの実行を監視するのに見られる高い CPU 使用率の多くを説明できます。コマンドライン。
このようなタスク中に CPU 使用率が高くなる理由は次のとおりです。PHP は一瞬で実行できるように設計されており、あらゆることを可能な限り高速に実行します。通常、CPU がどのように使用されるかは問題ではありません。これは非常に短い時間のためです。このようなタスクを長引かせると、問題がより明白になり、すべてのオペコードで発生するオーバーヘッドがプログラマーに見えるようになります。
実装を変更できないと言ったことは承知していますが、それでも完全な回答が必要です。このようなタスクは、 curl multi よりもThreadingにはるかに適しています。
アイドル状態の CPU で独自のデバイスを放置すると、1000 個のスレッドでも curl_multi と同じくらい多くの CPU を消費します。要点は、応答のすべてのバイトをダウンロードし、要求のすべてのバイトをアップロードするコードを正確に制御できることです。CPU 使用率がusleep を明示的に呼び出すか、意味のある方法で接続の使用を制限することで、「適切な」プロセスを実装できるという懸念があります。さらに、リクエストを別のスレッドで処理できます。
1000 スレッドを実行することをお勧めしません。おそらくそうではないでしょう。やるべきことは、「素敵な」効率的な方法でリクエストを作成してサービスすることを仕事とするStackable（ドキュメントを参照）を設計し、ワーカーのプール（github/pecl拡張ソースの例を参照）を設計して実行することです。新たにデザインされたリクエスト...