セカンダリHTTPコール用セロリの最適化

Question

セカンダリhttpコールの作成にセロリを使用しています。サードパーティのHTTP API呼び出しを呼び出すタスクは100以上もあります。いくつかのタスクはAPIを一括して呼び出します。たとえば、朝の午前4時に50万件のリクエストが発生します。また、1秒間にほぼ1回または2回要求を受け取るAPI呼び出しの連続ストリームもあります。

APIコールの応答時間の大部分は500〜800ミリ秒です。

私たちはセロリで非常に遅い送達速度を見ています。上記のタスクのほとんどでは、最大配信レートは約100/s（最大）からほぼ1/s（最小）です。私はこれが非常に貧しく、何かが間違っていると信じていますが、私はそれが何であるか把握できません。

3台のサーバーのクラスターで開始し、7台のサーバーのクラスターを段階的に作成しましたが、改善はありませんでした。我々は、オートスケールから固定された10,20,50,100人の作業者まで、さまざまな並行性の設定を試みました。結果のバックエンドはなく、ブローカーはRabbitMQです。

私たちのタスク実行時間は非常に短く、たいていは1秒未満ですので、プリフェッチカウントをさまざまな値に無制限にしようとしました。

--time-limit=1800 --maxtasksperchild=1000 -Ofair -c 64 --config=celeryconfig_production

サーバ64 G RAM、CentOSに6.6です。

あなたは何が間違っているのか、それを解決する方法の指針を教えていただけますか？

geventsと一緒に行くべきですか？私はそれが何であるかほとんど考えていませんが。

Answer 1

まず、GILは、より多くのマシンがより速く進むはずなので、大したことではありません。しかし、負荷がサーバの1つのコアにしか流れていないかどうかを確認してください。

あなたのケースでは、セロリ全体が良いアイデアかどうかはわかりません。これは、多くの機能を備えた素晴らしいソフトウェアです。しかし、それが必要ない場合は、その機能のいくつかが妨害される場合に備えて、より簡単なものを使用する方が良いです。小さなPoCを書き、pikaのような他のクライアントソフトウェアをチェックします。それが助けにならないなら、問題はインフラストラクチャーである。助けがあれば - あなたは解決策を持っています。 :)

何が起こっているのかは分かりません。それはIOで何かか、あまりにも多くのネットワークコールである可能性があります...私は戻って何かを見つけ出すために働くでしょう。統合テストを書いてください。ただし、完全なtcpスタックを使用するには、2-3台のマシンを使用するようにしてください。 CIを持って、そのテストを1日に1回、またはそれを実行して、正しいことが起こっているかどうかを確認してください。