Windowsワークフローを使用して、Webユーザーをナビゲーションパスに誘導したいと思います。
サーバーファームがあるため、これは各ユーザーのワークフローが長期化することを意味します。複数のサーバーが認識しなければならないもの。
これまでにプロトタイプを作成したのは、WorkflowApplicationとSQLPersistenceProviderの使用です。これは機能しますが、SQLServerのすべてのアクティビティとそのパフォーマンスについて懸念しています。
誰かがAppFabricキャッシュ永続性プロバイダー（ブログ投稿はこちら）を作成したことがわかりました。これは、ワークフローをSQLではなくRAMにハイドレイトすることを意味するため、私たちにとって魅力的です。しかし、彼らはそれが生産テストされていないことを明確に述べています。
何かアドバイス、考え、提案はありますか？
残念ながら、ほとんどのパフォーマンス関連の質問と同様に、これに対する良い答えは次のとおりです。実際のシナリオでテストして確認してください。
ショッピングカートスタイルのワークフローには純粋なSQL永続性を使用しており、パフォーマンスに問題はありません。いくつかのプロモートされたプロパティを抽出することで、ストレージのオーバーヘッドを追加します。ただし、私の負荷はあなたの負荷ではなく、私のワークフローはあなたのワークフローではないので、それがあなたのシナリオでうまく機能するという意味ではありません。
Webファームのシナリオについて私がアドバイスする一言は、sqlWorkflowInstanceStore /@instanceLockedExceptionAction属性を必ずに設定することAggressiveRetryです。この理由は、ファームシナリオでは通常、リクエストのパターンがdiffにルーティングされるためです。したがって、2つの呼び出しが連続して着信した場合、ワークフローの最初の要求はサーバーAに送信され、2番目の要求はサーバーBに送信される可能性があります。サーバーAは応答した可能性がありますが、永続性は応答と非同期であるため、 2番目の呼び出しがサーバーBに着信したときも、サーバーBは最初にロックを取得しない可能性があります。サーバーAは永続性を終了しているため、再試行ルーチンに入ります。指定しない場合はAggressiveRetry、BasicRetryが使用され、それは非常に低速で線形のアルゴリズムを使用します。これは、ワークフローのひどいサービスパフォーマンスのように見えます。AggressiveRetry一方、失敗が増えるほど「バックオフ」するアルゴリズムを使用します。サーバーAは間もなく終了する可能性があるため、通常、最初の数回の試行でロックを取得します。
AppFabric Cacheの実装に関する限り、耐久性が保証されていないため、その正確な実装を個人的に使用することはありません。キャッシュがダウンする可能性があり、ワークフローインスタンスなどを含む可能性のあるLRUオブジェクトをパージする必要がある場合があります。どちらかといえば、すべての書き込み/ロック呼び出しがSQLに対して行われるキャッシュリードスルー実装をお勧めしますが、ワークフローを逆シリアル化するための実際のデータがキャッシュから出てくる可能性があります。明らかにそれほど大きな影響はありませんが、SQLサーバーから読み取るよりも優れています。もう1つの可能性は、AppFabricCache1.1がキャッシュの読み取り/書き込みスループロバイダーを追加したことです。