実行時間を短縮するためにバックグラウンドスレッドを実行するWCFサービス

Question

私は、複数のクライアントにサービスを提供するコールごとのWCFサービスを持っています。私はいくつかのバックグラウンドプロセスを実行してサービスのスピードアップを図り、サービスの主な機能をブロックしたり遅くしたりしないようにしています。

主な機能はデータセットを返す必要があり、バックグラウンドスレッドはパラメータに基づいていくつかの統計情報を記録する必要があるということです。

コード：

Public Function GetAccountDetails(id As Integer) As AccountDetails 

    Dim retVal As New AccountDetails 
    Dim a As New Accounts 
    retVal = a.GetAccountDetails(id) 

    Dim t As New Thread(New ThreadStart(Sub() 
              Dim s As New Statistic 
              s.StatisticType = StatisticType.GetAccount 
              s.Parameter = id.ToString 
              s.Record() 
             End Sub)) 
    t.Start() 

    Return retVal 

End Function 

私はそれがクライアントにデータを返すからメインスレッドをブロックしません統計を記録するには、このバックグラウンドスレッドを使用している場合。

テストシナリオではうまくいきましたが、クライアントにデータを返す前にこのスレッドを実行せずにこのスレッドを実行するという危険性はありますか？ 統計データが失われる可能性はありますか？ サーバー側に潜在的なメモリの問題がありますか？

ありがとうございました。

Answer 1

「遅延書き込み」パターンの一種であるこの手法は珍しいことではありません。

主な問題点は以下のとおりです。

• あなたは統計表の一貫したビューを取得することはできません、それは実際の使用状況を常に遅れます。この「最終的な一貫性」は、通常、ロギングや統計には適していますが、トランザクション的に正しい更新が必要なものではありません。

• 統計情報テーブルの更新中にエラーを処理するメカニズムはありません。呼び出し元のサービスは引き続き問題を認識しません。これはあなたの状況には問題ではないかもしれません：とにかくすべてのことがログに記録され続けるならば、同じ戦略を続けることができます

• サービスが非常に混乱していると、それはあなたのサーバーを圧倒します。

この最後の点は、統計更新要求メッセージとその要求を処理できるワーカーサービスを実行するためのキュー（MSMQのようなもの）を導入することで対処できます。その後、一度に処理される更新の数を抑えることができます。これは、アーキテクチャの複雑さ（およびテスト！）を増やしますが、特にトラフィックが単一の一貫したフローでない場合は、システムを予測可能にスケーラブルにします。