は、私はC＃でEWSマネージAPI 2.0を介して呼ばれるのExchange Onlineからのいくつかの非常に長い応答時間に遭遇しています。私は抑制されていると思われますが、O365アカウントのAdminポータルでこれを証明できるものは見つかりません。私はいくつかの検索で見てきた適用されているあなたは、「マイクロ遅延」を示すメッセージを見ることができますが、私はので、私の質問は、C＃の/ EWSにこだわっているPowerShellを使用していることの結果：私は回答に戻ってくる時に見ることができるものがありますこれらのマイクロ遅延が適用されているかどうかを確認できるEWSコールに送信しますか？ところで、応答時間は私のコードを殺している100秒のタイムアウト時間に非常に近いです。
Thxを、 EWSを使用してマイクロ遅延を検出する方法はありますか？
100秒マイクロ遅延をins't、マイクロ遅延は（500ミリ秒でキャップされた）ミリ秒であり、より要求の大きい容積を遅らせることを目的としています。 （アプリがしようとしている場合例えば100のシーケンシャル要求がmicrodelayは、より多くのアプリを罰することによって、より時間をかけて、これらの要求の負荷を分散しまうことがあり、それは、サーバー上のリソース負荷を下げてしまいます）。要求を達成するために100秒を要するリクエストの1つは、おそらくリクエスト自体と関連しています。たとえば、検索フィルターの過度な使用や過剰な検索など、私の影響を抑えたり、バッチを使用している各リクエストをバッチすることで、マイクロ遅延が適用される可能性があります。
EWSは、スロットルの使用（新しいREST APIはバックこの点では少しより多くの情報が得られない）のメトリックを返しません。必要なのは、その情報を持つEWSログへのアクセスです。 EWSマネージAPIが行う各Exchange要求があり、クライアントRequestidは、返信用https://msdn.microsoft.com/en-us/library/office/dn720380(v=exchg.150).aspx
おかげでエントリが詳細をログに記録するための要求を関連付ける支援します。私は私ができるすべてのヘッダを設定したと思うが、私はもう一方の端にO365に話しているので、私はとにかくサポートコールせずに、任意のEWSログへのアクセスをしたん、私が始めた道は、探索しますこれまではあまり運がなかった。ところで、一貫性のある遅延が発生しているように見える呼び出しはOpenStreamingConnectionsであり、実際には返されるデータ量はありません。私のFindAppointmentsの中には時間がかかるものもありますが、1カレンダーから48時間分のapptsを求めていますので、そこにボリュームがあるとは思いません。クライアントの統計情報を参考にしていただければ幸いです。 – pjneary
OpenStreamingConnectionsがサブスクリプションのグループに対してこれをやっているのであれば？接続をmax（たとえば、グループあたり200）にロードすると、その数を減らしてパフォーマンスを向上させる方がよい場合があります。本当に遅くすべきではないFindAppointmentsの場合（インラインロードを使用して、会議出席者の詳細を取得する（EWSコードの一般的なパフォーマンスの問題、たとえばloadpropertiesforitemsを使用して解決する場合を除く）、ベースラインを確立することをお勧めします例えば最後の100個のアイテムを要求し、次にそのビューまたはフィルタと時間を比較する。 –
また、私は返信を感謝します。だから信じがたいですが、私は約6種類のカレンダーしか見ることができず、グループごとに1つまたは2つのサブスクリプションしか持っていません。私の現在の理論は、私が実行しているAzure VMのDNS設定に関連しています。別のVMでは、問題のVMで見られる遅延がどこにもありません。違いは：良いVMはAzure DHCP DNSサーバーを使用します。悪いVMには公開Google DNS（8.8.8.8）があります。 O365のFQDNは異なるIPAddrに解決されます。 （私は正しい軌道に乗ることを願っています！） – pjneary