Azureは弾性スケーリングという概念を採用しており、私はワーカーロールでこれを達成することができました。しかし、それは私ののWebロール（例えばMVCアプリ）私は（またはdescrease）を増加させるときには良い時間を決定する（またはどのように）監視するかわからないですランニングの数に来ますインスタンス。私は1つまたは複数のパフォーマンスカウンタを監視する必要があると思っていますが、どこから開始するのかはわかりません。Azure Webロールのスケーリングスレッシュホールドの定義
スケーリングの決定に比例してMVC Web Roleインスタンスの負荷を評価するベストプラクティスは誰も推奨できますか？
監視は通常、アプリケーション固有であるとして、この質問は、ビットオープンエンドです。あなたのアプリケーションのKPIを表すローカルサーバーで簡単に測定することから始めましょう：
たとえば：ネットワーク利用率を調べることができます。 This TechNet articleには、System Center for Windows Azureによって収集されたパフォーマンスカウンタが記載されています。例えば：
また、待機中のリクエスト数と待機時間を確認することもできます。お使いのNICを約提供するので
ネットワークの利用率は、興味深いものです。コアあたり100Mbpsであり、CPUやその他のリソースが十分に活用されていない場合でもボトルネックになる可能性があります。高帯域幅のシナリオを処理するには、さらに多くのインスタンスにスケールアウトする必要があります。
また、私はCPU使用率をあまり重要視しないようにしています。これは、測定が非常に簡単です（例では頻繁に表示されます）。あなたはそれのために払っているし、同様にできるだけ多くを使用する場合がありますので、近い容量でCPUを実行すると、通常良いことです。
までは、になります。これは少し注意深く処理する必要があります。 Windows Azureの計算時間は時間単位で課金されます。たとえば、11:50に余分なインスタンスにスケールアウトし、12:10に再度スケールインすると、2CPU時間がかかります。また、スケールアウトしないで新しい測定値を取得し、再度スケールバックできると判断します（事実上、インスタンスを追加したり減らしたりする一定のパルスを効果的に作り出します）。作業を容易にするために、Enterprise LibraryにあるAutoscaling Application Block（WASABi）を検討してください。これは焼き付けられたすべてのスケール規則（私が言及したものなど）を持ち、使用するのが非常に簡単です。
Davidの優れたコメントに加えて、AzureWatch @ http://www.paraleap.comのような自動スケーリング/モニタリングサービスの使用も検討してください。歴史的なチャートを使用すると、Davidが述べたリストのどの指標が高負荷 - それらに基づいて独自のスケーリングルールを作成することができます – Igorek