2

全て -

アプローチの質問の詳細。クライアントマシンからパフォーマンステストを行う必要があるWebサービスがあります。したがって、本質的には、要求/応答時間を視覚的に示すために、クイックWPFマルチスレッドアプリ（ゲージ/スピードメーターが含まれている）を作成しています。イベント駆動型-ボタンをクリックすると-アプリはリクエストを開始します。私は要求/応答にどれだけの時間がかかったかだけを気にし、応答値自体は気にしません（今のところ）。

これが私の現在の思考プロセスです：

1）できるだけ多くのスレッド（クライアントマシンが処理できる）を作成し、パフォーマンスを測定する必要があります。私が考えることができる2つのオプション-新しいスレッドメカニズムを作成する（スレッドを完全に制御できるようにする）か、backgroundworkerメカニズムを使用する（バックグラウンド処理からUIにその値を戻すことができるようにする）。仮定-スレッド作成コードをループする必要がある-したがって、両方のアプローチで複数のスレッドを作成し続けることができます。

2）進捗レポートは必要ないため、マルチスレッドアプローチを選択するための基準ではありません。

3）コールバックメソッドは必要ありません-値（Webサービスへの要求/応答にかかる時間）を返す必要があるためです

4）変数を値で更新する場合、使用可能な同期メソッドのいずれかを利用します。

5）Haventは実際に4.0フレームワークのTask APIを使用しましたが、それは私が考慮すべきことです。

上記のアプローチは見栄えが良いですか？それとも何かが足りませんか？

本当に助けてくれてありがとう!!!

4

1 に答える 1

1

多くの人がタスクを勧めていますが、これは良い考えだと思います。私自身も裸のスレッドを使用してもかまいません。どちらを使用するかについては、どちらでも問題ありません。注意すべき主なことは、例外処理の動作です。これは、2つの間で異なります。通常のスレッドで未処理の例外がある場合、プロセスがダウンするため、おそらく次のようなものが必要になります（過度に単純化されていない;））：

int errorCount = 0;

void Run()
{
    Thread t = new Thread(delegate()
    {
        try
        {
            // your code
        }
        catch (Exception )
        {
            Interlocked.Increment(ref errorCount);
        }
    });
}

一方、タスクには、エラーを処理するためのより制御された方法があります。Task.Wait関数を呼び出すと、タスクはAggregateExceptionにラップされてスローされます。

特に、ストレステスト中にタイムアウトエラーが発生すると想定しているため、例外について考えています。

Parallel.ForEachおそらく同様に見る価値がありますが、正直なところ、実際のシナリオではなくストレステストを試しているので、一度に実行しているスレッドの数を確認するためにそれを避けるかもしれません-PLINQのものはいくつかを行うと思いますクライアント側での負荷分散。

コールバックメソッドは、これらすべてのメソッドで簡単です。コールバックを渡すのではなく、メソッド呼び出しを使用するだけですが、それは実装の詳細です。

BackgroundWorkerは、実際にはUI関連の非同期操作を対象としており、この特定のコンテキストでは少し肥大化している可能性があるため、BackgroundWorkerには近づかないようにします。

于 2013-03-14T18:09:31.293 に答える