Windows Workflow Foundation アクティビティの速度はどのくらいですか? 答えられない質問であることは承知していますので、背景を説明させてください。
この問題は、ある種のビジネス ルール エンジンで解決する必要があります。一度に 300 ものルールを実装することができます。関連するものもあれば、関連しないものもあります。
1秒間に 1000 以上のルールを実行できると主張する 1 つの安価な BRE ( rulelab.net ) を試してみました。実行速度は非常に速いようですが、中にはほんの一握りのルールしかありませんでした。
ワークフローでのデータの操作を見て遊んでみましたが、if ステートメントが 1 つしかない場合、実行速度がかなり遅いようです。
全体として、私は Microsoft WF のパフォーマンスに満足しているわけではありません。従来の BRE を使用したほうがよいのでしょうか? 何かご意見は？
Windows Workflow Foundation は、多くのアプリケーションにとって十分に高速です。単純な noop アクティビティのテストでは、1 秒あたり 350K 以上の操作を実行しました。もちろん、アプリケーションは実際のビジネス ロジックを実行しますが、これにはさらに時間がかかりますが、評価する価値があることは明らかです。
「1秒間に1000を超えるルールを実行できる」という例は、少し奇妙です。通常のビジネスルールエンジンは、パフォーマンスを自慢するときに「時間間隔ごとのファクトオブジェクトの数」と言います。これは、ほとんどの場合（そして私はこの業界にかなり長い間携わっています）、システムがファクトオブジェクトのコレクション（100万または1つだけ）を受け取り、1つまたはいくつかのルール。RETEベースのエンジンは、明らかな理由で遅くなります。そのため、ほとんどの場合、RETEアルゴリズムは必要ありません。しかし、あなたの例でも、その数は堅実なBREには少なすぎます。通常、エンジンがルールをキャッシュせず、反復ごとに各ルールをコンパイルする必要がある場合でも、エンジンは1秒あたり少なくとも50万のルール評価を実行すると予想されます。ただし、各ルールは外部で何も実行せず、コストのかかる計算も含まれていません。rulelab.netの内部はわかりませんが、速度が遅いということは、ルールがネイティブオブジェクトにコンパイルされないか、ルールが非常に悪い方法で評価されることを意味します。
あなたの質問からは、ワークフロー/BRE が必要な理由がまったくわかりません。ワークフロー エンジンとルール エンジンは、さまざまな問題や課題に対応するように設計されています。まず最初に、ビジネスの観点から自分の目標と達成しようとしていることを知ることです。ワークフローやビジネス ルール エンジンが必要な理由は何ですか? ワークフローや BRE で解決しようとしている課題/ニーズ/要件は何ですか? あなたの質問からは、それはまったく明確ではありません。
なぜ、いつ、どちらを選択したのかを実際に示す投稿があります。または、両方を一緒に使用することになる場合もあります。ポイントは、2 つの異なるもののパフォーマンスの比較を求めているということです。