問題タブ [furrr]

Web API (NCBI entrez) から大規模なデータセットを取得する必要があります。これにより、1 秒あたりの要求数が 10 などに制限されます (サンプル コードでは、API キーなしで 3 つに制限されます)。次のように、furrr の future_* 関数を使用してリクエストを並列化し、できるだけ早くリクエストを取得しています。

明らかに、nrequest > 10（または制限が何であれ）、レート制限にすぐに違反します。

これに対する一見明白な単純な解決策が 2 つありますが、どちらも機能しているようです。1 つは、次のように、リクエストを行う前にランダムな短い遅延を導入することです。

2 つ目は、次のように、レート制限に設定されたセマフォでセマフォパッケージをplan(multiprocess,workers=<max_concurrent_requests>)使用するか、または使用して、同時要求の数をレート制限に制限することです。

ただし、私が本当にできるようにしたいのは、同時要求の数ではなく、要求レートを制限することです。Python で async io http requests を使用してこれを行う方法について、Quentin Pradet による素晴らしい投稿があります。これを R に適応させようとしましたが、future_* 関数内のスレッド/プロセス間で共有される変数は、実際に共有されるのではなくコピーされるという問題に遭遇しました。スレッド/プロセスに依存しているため、このメソッドが機能するために依存しているカウンター バケットを実装することはできません。

同時リクエストの数を必ずしも制限せずに、並列リクエストのレートを制限する賢い方法はありますか? それとも、これを考えすぎて、数を制限することに固執する必要がありますか?

これまでlapplyに R で並列を使用する最も簡単な方法は、次のコード例を使用することでした。

これには、結果の進行状況バーを提供する非常に便利な機能があり、 を設定することにより、並列計算が必要ない場合に同じコードを非常に簡単に再利用できますcl = NULL。

ただし、私が指摘した 1 つの問題は、pblapplyがリストをバッチでループしていることです。たとえば、1 つのワーカーが特定のタスクで長時間スタックしている場合、残りのワーカーはそのタスクが終了するのを待ってから、新しいバッチのジョブを開始します。特定のタスクでは、これによりワークフローに多くの不要な時間が追加されます。

私の質問: ワーカーを独立して実行できる類似の並列フレームワークはありますか? 進行状況バーとコードを再利用できる機能はcl=NULL、大きなプラスになります。

の既存のコードを変更してpbapply、このオプション/機能を追加することは可能でしょうか?

必要なプランを設定しようとしていますが、次のエラーが発生します。

エラーは次のとおりです。

また：

/ プランのworkers、lazy、gcおよびその他のパラメータを設定する方法を教えてください。multisessionmulticore

私のRバージョンは次のとおりです。