7

SOA 環境における比較的典型的な .NET 4 システム (つまり、Windows Server 2008 R2、IIS 7 上の RESTful Web サービス、NServiceBus メッセージング用の Windows サービス、SQL Server 2008 R2 など) を考えると、ベスト プラクティスまたはデファクト ソリューションは何ですか?実稼働環境で 24 時間年中無休のパフォーマンス監視を実行するためのエンタープライズ価格タグ)?

必ずしも CPU/メモリ/ディスク IO の消費量ではなく、たとえば、1 分あたりの createAccount() 呼び出しの数、generateResponse() メソッドにかかる平均時間、および generateResponseStarted と generateResponseComplete (メソッド呼び出され (サードパーティを呼び出すことができます)、応答はそれぞれ返される準備ができています)。

グーグルで調べた後、オプションは低レベルのプロファイラー（dotTraceなど）とパフォーマンスカウンターの実装、およびPerfMonまたはその他のOpManagerタイプの製品でのそれらの使用にあるようです。

あなたは何をお勧めします？ライブ アプリケーションにパフォーマンス カウンターを実装すると、運用システムのパフォーマンスが大幅に低下しますか? そうでない場合、.NET での実装を合理化する優れたライブラリはありますか? はいの場合、memory-disk-cpu 以外のアプリケーションのパフォーマンスをどのように監視していますか?

@ライアン・ヘイズ

ありがとうございます。運用システムで異常な速度低下やスパイクが発生するのを確認する方法を探しています。たとえば、ストレス テスト中はすべて問題ありませんでしたが、何らかの理由で、信頼しているサード パーティに問題が発生したり、スレッド ロックが原因で DB が遅くなったり、SAN が道を譲ったり、その他の予期しないシナリオが発生したりします。低レベルのプロファイリングはオーバーヘッドが大きすぎますが、問題がある場合にのみカウンターをオンにするのはその時点では遅すぎます。さらに、比較するための履歴データが失われます (デルタが許容可能なしきい値を超えた場合に備えて、何らかの警告システムが必要になります)。人々が本番システムのパフォーマンスを監視する方法と、メモリ/CPU/サーバーに関連しない種類の監視に最適なアプローチは何かと思っています。

4

2 に答える 2

2

AlertGridを試すことができます。これはあなたの問題の解決策になるようです。

アプリケーションから AlertGrid にさまざまなパラメーターを送信できます (新しいアカウント名、重要なロジックの実行時間など)。AlertGrid サービスは、データに対していくつかのことを実行できます。まず第一に、送信したパラメーターで構築されたいくつかの通知ルールを処理できます (重要なことを行う時間 > X 秒 -> 担当者に SMS を送信する場合など)。

2 週間以内に、AlertGrid に多数の新機能が追加されます。あなたにとって最も重要なのは、システムから受け取ったパラメーターをプロットする可能性です。

AlertGrid はシステムからパラメータを検出できないことに注意してください。代わりにパラメータを送信する必要があります。これは追加の作業のように見えるかもしれませんが、いくつかの特殊なツールのインストールと構成に必要な時間に匹敵すると考えています. 一方、このアプローチのおかげで、AlertGrid はいくつかの制限を克服しています (http 要求を送信できるものなら何でも統合できます)。

AlertGrid でアカウントを作成し、インタラクティブなチュートリアルに合格すると、はるかに理解しやすくなると思います。

お気づきかもしれませんが、私はAlertGridチームの開発者です:)

免責事項: この記事を書いている時点で、AlertGrid の価格が近い将来引き下げられることがわかっています。そのため、今は見ないでください。価格の詳細については、サポート ラインにお問い合わせください。無料のアカウントが利用可能で、最初は十分です。

于 2010-08-09T17:50:49.463 に答える
0

ここでの質問は、実際にパフォーマンス モニタリングから何を学ぼうとしているのかということです。

  • コードを高速化しますか? 次に、テスト環境でプロファイリング ツールを使用して、コードを改善できる場所を見つけることをお勧めします。

  • システムが処理できる最大のビートを知りたいですか? 次に、テスト環境で負荷テストを実行することをお勧めします。システムを破壊せずにどれだけプッシュできるかが正確にわかっている場合は、モニタリングを本番環境に導入する必要はありません。

本番環境では、おそらくパフォーマンスを最大化する必要があります。これを行うには、本番環境にパフォーマンス モニターを配置する必要がないように、テスト環境を強化して確実なメトリックを取得するのが一般的です。本番環境では、いつそのピークに達したかを知りたいだけで、その後、適切に劣化するか、適切と思われるものを何でも使用できます。一般に、システム (ハードウェアを除く) のパフォーマンスを監視し、例外的なパフォーマンスの癖を記録するには、適切なログ記録が最善の方法です。

ただし、すべてのシステムは異なり、マイレージは異なる場合があります。プロファイリングを本番環境で実行しなければならない例外的なケースが常に存在するため、これは誰もが行う方法ではなく、提案として受け取ってください。

于 2010-08-09T15:33:37.983 に答える