6

私は現在、可能な状態の更新を毎分数回送信する数千のオブジェクトの状態を並行して追跡する必要があるシステムを扱っています。さらに、追加の計算を実行する必要があります (CPU を使用するだけで、遅い IO はありません)。

現在、カスタム ステート マシンの実装を使用しています。ただし、WF はシステムの他の部分で使用されるため、WF ステート マシンは少数 (<5) の状態を持つシナリオに適しているのではないかと思います。

パフォーマンスに関しては、オーバーヘッドが大きすぎるのではないかと心配しています。MS のドキュメントは WF ステート マシンのパフォーマンスに関するトピックを実際にはカバーしていないため、一部の SO メンバーが WF ステート マシンのパフォーマンスに関する情報またはリソースを持っているのだろうか?

よろしくj。

4

4 に答える 4

5

.Netベースの高性能ステートマシンをお探しの場合は、ステートレスをお勧めします。プロジェクトサイトからの抜粋は次のとおりです。

ほとんどの標準的なステートマシン構造がサポートされています。

  • 任意の.NETタイプ（数値、文字列、列挙型など）の状態とトリガーの一般的なサポート
  • 階層状態状態の開始/終了イベント
  • 条件付き遷移をサポートするGuard句
  • イントロスペクション

いくつかの便利な拡張機能も提供されています。

  • 状態を外部に保存する機能（たとえば、LinqからSQLに追跡されるプロパティ）
  • パラメータ化されたトリガー
  • リエントラント状態

構成は次のとおりです。

var phoneCall = new StateMachine<State, Trigger>(State.OffHook);

phoneCall.Configure(State.OffHook)
    .Permit(Trigger.CallDialed, State.Ringing);

phoneCall.Configure(State.Ringing)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.CallConnected, State.Connected);

phoneCall.Configure(State.Connected)
    .OnEntry(() => StartCallTimer())
    .OnExit(() => StopCallTimer())
    .Permit(Trigger.LeftMessage, State.OffHook)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.PlacedOnHold, State.OnHold);

// ...

phoneCall.Fire(Trigger.CallDialled);
Assert.AreEqual(State.Ringing, phoneCall.State);

また、Genericsを実装しているため、intまたはstringを使用して状態とトリガーを表すことができ、データベースまたはORMと非常に簡単に統合できます。美しさは、心配する必要のある追加のランタイムホストがないことです。オブジェクトまたはレコードから現在の状態をステートマシンにロードするだけで、準備は完了です。

于 2010-01-26T23:44:25.207 に答える
1

これはパフォーマンスに直接関係するものではありませんが、最終的に WF 4.0 に移行することを計画している場合は、StateMachineActivity がうまくいかない可能性が高いことに注意してください。

于 2009-08-21T02:10:58.840 に答える
1

Microsoft は現在、サーバー製品で WF を使用しており、これを拡張しています。たとえば、WF エンジンは、Share Point Server (MOSS) と BizTalk Server に含まれています。どちらも非常にうまくスケーリングし、スケール アウト シナリオを可能にします。つまり、より多くのコンピューティング パワーが必要な場合は、負荷分散されたクラスターに (安価な) ハードウェアを追加します。

HTH、トーマス

于 2009-08-20T13:36:02.393 に答える