複数のビデオ クリップをフレームごとに処理するアプリケーションを並列化したいと考えています。クリップごとの各フレームのシーケンスは重要です (明らかに)。TPL Dataflow を使用することにしたのは、これがデータフロー (ムービー フレームがデータである) の良い例であると信じているからです。
したがって、データベースからフレームをロードするプロセスが 1 つあります (たとえば、500 のバッチで、すべてまとめて)
Example sequence:
|mid:1 fr:1|mid:1 fr:2|mid:2 fr:1|mid:3 fr:1|mid:1 fr:3|mid:2 fr:2|mid:2 fr:3|mid:1 fr:4|
それらを BufferBlock に投稿します。この BufferBlock に、ActionBlocks をフィルターにリンクして、MovieID ごとに 1 つの ActionBlock を持つようにしました。これにより、ある種のデータ パーティショニングが得られます。各 ActionBlock はシーケンシャルですが、理想的には、複数のムービーの複数の ActionBlock を並行して実行できます。
上記のネットワークは機能しており、並行して実行されていますが、私の計算では、同時に実行されている ActionBlock は 8 ~ 10 個にすぎません。各 ActionBlock の実行時間とその約 100 ~ 200 ミリ秒の時間を計りました。少なくとも 2 倍の同時実行性を実現するには、どのような手順を実行できますか?
アクション デリゲートを非同期メソッドに変換し、ActionBlock アクション デリゲート内でデータベース アクセスを非同期にしようとしましたが、役に立ちませんでした。
編集:追加レベルのデータ パーティショニングを実装しました。奇数 ID のムービーのフレームは ServerA で処理され、偶数ムービーのフレームは ServerB で処理されます。アプリケーションの両方のインスタンスが同じデータベースにヒットしました。問題が DB IO である場合、処理されたフレーム数の合計に改善は見られません (または 20% 未満の非常にわずかなもの)。しかし、私はそれが倍増していると見ています。したがって、これにより、Threadpool はより多くのフレームを並行して実行するために、より多くのスレッドを生成していないと結論付けることができます (両方のサーバーはクアッドコアであり、プロファイラーはアプリケーションごとに約 25 ~ 30 のスレッドを示します)。