2

多数の相互依存サービスのパフォーマンス/負荷テストを行う必要があります。それらはすべてnet.tcpを使用し、ほとんどがデュプレックスコントラクトと内部キューを使用します。[lock（syncRoot）{if（queue.Empty）Thread.Wait（）;を使用してPOCOキュークラスを処理しました。}]

これが私が思いついたアプローチです：

  1. パフォーマンステスト対象のWCFサービスを特定する
  2. 各サービスに関連するパフォーマンスカウンターを特定する
  3. テスト対象のサービスを介して実行を行う論理的な開始点を特定します
  4. 各サービスに対してVS.Netを使用して単体テストを自動生成する
  5. 特定の機能テストを作成します（たとえば、「注文する」というユースケースを使用して、関連するサービスへのすべての呼び出しを行い、通常、必要な機能のほとんどすべてを実行するテストを作成できます）
  6. ＃5の実行からのトレースファイルを使用して単体テストを生成します[CodePlexからのWCF負荷テストを使用]（これは、デバッグ環境で本番/フィールドのユーザーエラーを再現するための理想的なツールのようです。免責事項：ツールは使用されていません。印象プロジェクトの説明を読んでから）
  7. 上記のテストは、自動生成された入力データを使用して呼び出しを行うように調整できます。
  8. さまざまなコードパスが実行されるように、入力にバリエーションを導入します
  9. パフォーマンスカウンターからのログデータ
  10. ボトルネックを分析して特定する

質問：

  1. より良いアプローチはありますか？
  2. 内部キューを使用するサービスの場合、stdパフォーマンスカウンターを使用してパフォーマンスを測定することが問題になります。カスタムカウンターが必要な場合がありますか？
  3. ＃1が当てはまる場合、テスト対象のサービスのコードを変更せずに顧客カウンターを導入する方法はありますか？
  4. 機能テストの結果を気にする必要がありますか？
  5. WCFサービスのSLAを[非侵入的に]実装する方法はありますか？（処理された要求、発生した例外、応答時間などのカウンターからの十分なデータがある場合、SLAを検証できるはずです-5分以内に200,000の要求を処理し、各要求の応答時間は2秒です-私の質問は、SLAを指定するだけで、製品/ツールが舞台裏ですべての配管を実行し、表形式の回答を得ることができるかどうかということです。 :)）
  6. 余談ですが、WCFサービスの内部でリクエストをキューに入れるための最良の方法は何ですか？
4

1 に答える 1

1

うわー…タイトルは間違いなく氷山の一角でした！ここでの回答が的外れでないことを願っています。:)

  1. WCF サービスのパフォーマンス テストは、Microsoft Team Test、Borland Silk Performer、Mercury LoadRunner、または LoadGen やカスタム テスト ハーネスなどのテスト ツールを使用して、さまざまな方法で実行できます。私の好みは、テストツールを使用してそのテストの複数の同時インスタンス（仮想「ユーザー」）をスピンアップしながら、ある種の機能単体テストを作成してからそのテストにデータをフィードする際に行ったアプローチを試みることです。 . ほとんどの商用テスト ツールのツールは、この種のテストを非常に容易にします。通常、最大の課題は、アプリケーションのテストをサポートするためにテスト ケースとテスト データを維持することです。

  2. WCF には、パフォーマンスに関連するカウンターが組み込まれていません。まさに盲点です。確かに、サーバーに対して行われている接続の数を確認できますが、これは大まかな情報であり、これらの要求にサービスを提供しているサービスを知りたい場合があります。噂によると、Microsoft の「Dublin」は、WCF/WF に豊富なホスティング環境を提供する一環として、ホストされたサービスのパフォーマンス カウンターを表示する予定です。私たちは、実際に何が揺れ動くかを待つ必要があります.

  3. 既存のコードベースに影響を与えずに WCF サービスを計測する必要がある場合は、サービスに適用できる WCF の動作からどれだけのマイレージを得ることができるかを調べます。このカスタム動作により、必要なパフォーマンス カウンターが表示される可能性があります。

  4. はい。機能テストの結果 (つまりパフォーマンス?) が気になります。警告は、無視できるスタートアップ (JIT) が存在する可能性があることです。おそらく、機能テストの実行をプロファイリングして実行メトリクスを取得することを検討しますが、パフォーマンスの実行中にコード プロファイリングをオンにすることはありません。

  5. SLA の場合も、カスタム動作が解決策になる可能性があります。運用メトリックをデータベースに記録し、それを報告することができます。Amberpoint や SOA Software などの商用製品もこれをサポートします (パフォーマンス カウンターを含む)。

  6. wcf サービスへのリクエストをキューに入れていますか? 特に要求を耐久性のあるものにしたい場合は、すぐに net.msmq バインディングを考えます。

于 2009-04-15T03:28:22.443 に答える