ベースラインとパフォーマンス履歴を使用して、Office 365 のパフォーマンスをチューニングする

Office 365とビジネスの間の接続パフォーマンスを確認する簡単な方法がいくつかあります。これによって、接続の大まかなベースラインを確立できます。 クライアント コンピューター接続のパフォーマンス履歴を把握すると、問題の早期発見、問題の特定、予測に役立ちます。

パフォーマンスの問題に慣れていない場合、この記事は一般的な質問を検討するのに役立ちます。 表示される問題がパフォーマンスの問題であり、Office 365サービス インシデントではないことがわかります。 良好なパフォーマンスを長期的に計画するにはどうすればよいでしょうか。 パフォーマンスに目を光らうにはどうすればよいですか。 Office 365を使用している間にチームまたはクライアントのパフォーマンスが低下していて、これらの質問について疑問がある場合は、読んでください。

重要

クライアントとOffice 365の間でパフォーマンスの問題が発生しましたか? Office 365のパフォーマンスのトラブルシューティング 計画で説明されている手順に従います。

Office 365パフォーマンスについて知っておくべきこと

Office 365は、自動化と実際のユーザーによって監視される大容量の専用 Microsoft ネットワーク内に存在します。 Office 365 クラウドの保守の一部は、可能な限りパフォーマンスのチューニングと合理化です。 Office 365 クラウドのクライアントはインターネット経由で接続する必要があるため、Office 365 サービス全体でパフォーマンスを微調整する取り組みも継続的に行われます。

パフォーマンスの向上はクラウドで実際に停止することはありません。そのため、クラウドを正常かつ迅速に維持する操作も行われません。 場所からOffice 365に接続する際にパフォーマンスの問題が発生した場合は、サポート ケースから開始したり、待ったりすることはお勧めしません。 代わりに、"内側" から問題の調査を開始する必要があります。 つまり、ネットワーク内から開始し、Office 365に進む方法です。 サポートでケースを開く前に、データを収集し、問題を調査し、解決する可能性のあるアクションを実行できます。

重要

Office 365の容量計画と制限に注意してください。 この情報を使用すると、パフォーマンスの問題を解決しようとすると、曲線の前に進みます。 Microsoft 365 とOffice 365サービスの説明へのリンクを次に示します。 これは中央ハブであり、Office 365によって提供されるすべてのサービスには、ここから独自のサービスの説明にアクセスするリンクがあります。 つまり、SharePoint Online の標準制限を確認する必要がある場合は、たとえば、[ SharePoint Online サービスの説明 ] をクリックし、 SharePoint Online の [制限] セクションを見つけます。

パフォーマンスがスライディング スケールであることを理解して、トラブルシューティングに進む必要があります。 理想化された価値を達成し、それを永続的に維持する必要はありません。 大量のユーザーのオンボーディングや大規模なデータ移行などの高帯域幅タスクはストレスが発生するため、パフォーマンスへの影響を 計画 してください。 パフォーマンスターゲットの概念は大まかにあるはずですが、多くの変数がパフォーマンスに再生されるため、パフォーマンスは異なります。

パフォーマンスのトラブルシューティングは、特定の目標を達成し、それらの数値を無期限に維持することではなく、すべての変数を考慮して既存のアクティビティを改善することです。

パフォーマンスの問題はどのようなものですか?

まず、発生している内容が、サービス インシデントではなく、実際にパフォーマンスの問題であることを確認する必要があります。 パフォーマンスの問題は、Office 365のサービス インシデントとは異なります。 それらを区別する方法を次に示します。

サービス インシデントは、Office 365 サービス自体に問題がある場合に発生します。 Microsoft 365 管理センターの [現在の正常性] に赤または黄色のアイコンが表示される場合があります。 Office 365に接続しているクライアント コンピューターのパフォーマンスが低下している場合があります。 たとえば、現在の正常性レポートに赤いアイコンが表示され、Exchange の横に [調査中] と表示された場合は、組織内のユーザーから、Exchange Onlineを使用しているクライアント メールボックスが低速であると不平を言う呼び出しを受けることもあります。 その場合、Exchange Onlineのパフォーマンスがサービスの問題の犠牲になったと見なすのが妥当です。

Exchange を除くすべてのワークロードが緑色で表示されたOffice 365正常性ダッシュボード。このダッシュボードには、サービスの復元済みが表示されます。

この時点で、Office 365管理者は現在の正常性を確認し、多くの場合、システムのメンテナンスを最新の状態に保つために詳細と履歴を表示する必要があります。 現在の正常性ダッシュボードは、サービスに対する変更と問題についてユーザーを更新するために作成されました。 正常性履歴に書かれたメモと説明(管理者から管理者まで)は、測定に役立ち、継続的な作業に関する投稿を維持するために用意されています。

Exchange Online サービスが復元されたこととその理由を説明するOffice 365正常性ダッシュボードの図。

パフォーマンスの問題はサービス インシデントではありませんが、インシデントによってパフォーマンスが低下する可能性があります。 パフォーマンスの問題は次のようになります。

  • パフォーマンスの問題は、管理センター の現在の正常性 がサービスのレポートに関係なく発生します。

  • フローに使用される動作は、完了または完了するまでに長い時間がかかります。

  • 問題もレプリケートできます。または、適切な一連の手順を実行すると発生することがわかります。

  • 問題が断続的な場合は、引き続きパターンが存在する可能性があります。 たとえば、午前 10 時までに、常にOffice 365にアクセスできないユーザーからの呼び出しが行われることがわかります。 呼び出しは正午頃に終了します。

この一覧はおそらく使い慣れているように聞こえます。よく知られているかもしれません。 パフォーマンスの問題に気づいたら、"次に何をしますか?この記事の残りの部分は、正確に判断するのに役立ちます。

パフォーマンスの問題を定義してテストする方法

パフォーマンスの問題は時間の経過と共に発生することが多いため、実際の問題を定義するのは困難な場合があります。 問題コンテキストの適切なアイデアを持つ適切な問題ステートメントを作成し、繰り返し可能なテスト手順を実行する必要があります。 十分な情報を提供しない問題ステートメントの例を次に示します。

  • 受信トレイから予定表への切り替えは、以前は気づかなかったもので、今ではコーヒーブレイクになりました。 以前と同じように動作させることができますか?

  • 自分のファイルを SharePoint Online にアップロードすることは、永久に時間がかかっています。 午後は遅くなるのに、それ以外の時間は速いのはなぜですか? 高速にすることはできませんか?

上記の問題ステートメントには、いくつかの大きな課題があります。 具体的には、扱うあいまいさが多すぎます。 以下に例を示します。

  • 受信トレイと予定表の切り替えがノート PC でどのように動作したかは不明です。

  • ユーザーが "高速にすることはできません"と言うとき、"高速" とは何ですか?

  • "forever" の期間はどのくらいですか? 数秒ですか? または多くの分? または、ユーザーが昼食を取り、アクションが戻ってから 10 分後に終了する可能性がありますか?

管理者とトラブルシューティングツールは、このような一般的なステートメントから問題の 詳細 を認識できません。 たとえば、問題がいつ発生し始めたかはわかりません。 トラブルシューティング ツールは、ユーザーが自宅で作業していることを知らない場合があり、ホーム ネットワーク上で低速の切り替えが発生した場合だけです。 または、ユーザーがローカル クライアントで他の RAM 集中型アプリケーションを実行していること。 管理者は、ユーザーが古いオペレーティング システムを実行しているか、最近の更新プログラムを実行していないかわからない場合があります。

ユーザーがパフォーマンスの問題を報告すると、収集する情報が多くなります。 情報の取得と記録は、問題のスコープと呼ばれます。 パフォーマンスの問題に関する情報を収集するために使用できる基本的なスコープの一覧を次に示します。 この一覧は完全ではありませんが、次の作業を開始する場所です。

  • 問題は何日に発生し、どの時間帯または夜間に発生しましたか?

  • 使用していたクライアント コンピューターの種類と、ビジネス ネットワーク (VPN、ワイヤード、ワイヤレス) への接続方法

  • リモートで作業していたか、それともオフィスにいましたか?

  • 別のコンピューターで同じアクションを試し、同じ動作が表示されましたか?

  • 取り下げたアクションを記述できるように、問題を引き起こしている手順について説明します。

  • パフォーマンスは秒単位または分単位でどのくらい遅いですか?

  • 世界のどこにいますか?

これらの質問の中には、他の質問よりもわかりやすいものがあります。 ほとんどのユーザーは、トラブルシューティングツールに問題を再現するための正確な手順が必要だと理解しています。 結局のところ、何が間違っているかを記録する方法と、問題が修正されたかどうかを他にテストする方法は何ですか? 「問題が発生した日時は何ですか?」や「世界のどこにいるか」など、一緒に使用できる情報は、あまり明らかではありません。 ユーザーがいつ作業していたかによって、数時間の時間差は、会社のネットワークの一部でメンテナンスが既に進行中であることを意味する場合があります。 たとえば、会社にはハイブリッド SharePoint Search のようなハイブリッド実装があり、SharePoint Online とオンプレミスの SharePoint Server 2013 インスタンスの両方で検索インデックスを照会できます。更新はオンプレミス ファームで進行中である可能性があります。 会社がすべてクラウド内にある場合、システム メンテナンスには、ネットワーク ハードウェアの追加または削除、全社的な更新プログラムのロールアウト、DNS の変更、またはその他のコア インフラストラクチャが含まれる場合があります。

パフォーマンスの問題のトラブルシューティングを行うときは、少し犯罪現場に似ています。証拠から結論を導き出すには、正確で観察する必要があります。 これを行うには、証拠を収集して適切な問題の声明を取得する必要があります。 これには、コンピューターのコンテキスト、ユーザーのコンテキスト、問題が発生した時点、およびパフォーマンスの問題を公開した正確な手順が含まれている必要があります。 この問題に関する声明は、ノートの最上位ページに配置し、維持する必要があります。 解決に取り組んだ後に問題ステートメントをもう一度調べて、実行したアクションが問題を解決したかどうかをテストして証明する手順を実行します。 これは、作業がいつ実行されているかを知る上で重要です。

パフォーマンスが良いときにどのように見えるかご存知ですか?

運が悪ければ、誰も知りません。 誰も番号を持っていませんでした。 つまり、「Office 365で受信トレイを持ち上げるのにどれくらいの時間がかかったか」、または「経営陣が Lync Online 会議を開いたとき、どのくらいの時間がかかったか」という簡単な質問には誰も答えられません。これは、多くの企業にとって一般的なシナリオです。

ここで不足しているのは、パフォーマンス ベースラインですか?

ベースラインは、パフォーマンスのコンテキストを提供します。 会社のニーズに応じて、ベースラインを頻繁に実行する必要があります。 大企業の場合は、運用チームがオンプレミス環境のベースラインを既に取得している可能性があります。 たとえば、月の最初の月曜日にすべての Exchange サーバーにパッチを適用し、3 番目の月曜日にすべての SharePoint サーバーにパッチを適用する場合、重要な機能が動作していることを証明するために、運用チームには、パッチ適用後に実行されるタスクとシナリオの一覧が含まれている可能性があります。 たとえば、受信トレイを開き、[送信/受信] をクリックしてフォルダーを更新するか、SharePoint でサイトのメイン ページを参照し、エンタープライズ検索ページに移動し、結果を返す検索を実行します。

アプリケーションがOffice 365されている場合、最も基本的なベースラインの一部は、ネットワーク内のクライアント コンピューターからエグレス ポイント、またはネットワークを離れてOffice 365に出るポイントまでの時間 (ミリ秒単位) を測定できます。 調査と記録に役立つベースラインをいくつか次に示します。

  • クライアント コンピューターとエグレス ポイント (プロキシ サーバーなど) の間のデバイスを識別します。

    • 発生するパフォーマンスの問題に対してコンテキスト (IP アドレス、デバイスの種類、デバイスの種類など) が発生するように、デバイスを把握しておく必要があります。

    • プロキシ サーバーは一般的なエグレス ポイントであるため、Web ブラウザーを確認して、使用するように設定されているプロキシ サーバー (存在する場合) を確認できます。

    • ネットワークを検出してマップできるサード パーティ製のツールがありますが、デバイスを知る最も安全な方法は、ネットワーク チームのメンバーに問い合わせすることです。

  • インターネット サービス プロバイダー (ISP) を特定し、連絡先情報を書き留めて、帯域幅の量を確認します。

  • 社内で、クライアントとエグレス ポイントの間のデバイスのリソースを特定するか、ネットワークの問題について話す緊急連絡先を特定します。

ツールを使用した簡単なテストで計算できるベースラインを次に示します。

  • クライアント コンピューターからエグレス ポイントまでの時間 (ミリ秒)

  • エグレス ポイントからOffice 365までの時間 (ミリ秒単位)

  • 参照時にOffice 365の URL を解決するサーバーの世界の場所

  • ISP の DNS 解決の速度 (ミリ秒単位)、パケット到着の不整合 (ネットワーク ジッター)、アップロード時間、ダウンロード時間 (ミリ秒)

これらの手順を実行する方法に慣れていない場合は、この記事で詳しく説明します。

ベースラインとは何ですか?

問題が発生した場合の影響はわかりますが、過去のパフォーマンス データがわからない場合は、それがどれほど悪くなったか、いつ起きたかについてのコンテキストを持つことは不可能です。 そのため、ベースラインがなければ、パズルを解決するための重要な手がかりがありません。パズル ボックスの画像。 パフォーマンスのトラブルシューティングでは、 比較ポイントが必要です。 単純なパフォーマンス ベースラインを実行することは困難ではありません。 運用チームは、スケジュールに従ってこれらを実行するタスクを割り当てることができます。 たとえば、接続が次のようになります。

クライアント、プロキシ、Office 365 クラウドを示す基本的なネットワーク グラフィック。

つまり、ネットワーク チームに確認を行い、プロキシ サーバーを介して会社からインターネットに移行し、クライアント コンピューターがクラウドに送信するすべての要求をプロキシが処理することを確認しました。 この場合は、接続の簡略化されたバージョンを描画して、すべての介入デバイスを一覧表示する必要があります。 次に、クライアント、エグレス ポイント (インターネット用のネットワークを離れる場所)、Office 365 クラウド間のパフォーマンスをテストするために使用できるツールを挿入します。

クライアント、プロキシ、クラウドを使用した基本的なネットワークと、PSPing、TraceTCP、およびネットワーク トレースに関するツールの提案。

パフォーマンス データを見つけるために必要な専門知識が豊富であるため、オプションは [シンプル ] と [ 詳細設定] として一覧表示されます。 ネットワーク トレースは、PsPing や TraceTCP などのコマンド ライン ツールを実行する場合と比較して、多くの時間がかかります。 この 2 つのコマンド ライン ツールは、OFFICE 365によってブロックされる ICMP パケットを使用せず、クライアント コンピューターまたはプロキシ サーバー (アクセス権がある場合) からOffice 365に到着するまでにかかる時間をミリ秒単位で与えるため、選択されました。 1 台のコンピューターから別のコンピューターへの各ホップは時間の値で終わり、ベースラインに最適です。 重要な点として、これらのコマンド ライン ツールを使用すると、コマンドにポート番号を追加できます。これは、セキュリティで保護されたソケット層とトランスポート層セキュリティ (SSL および TLS) で使用されるポートであるポート 443 経由で通信Office 365ため、便利です。 ただし、他のサード パーティ製ツールは、状況に応じてより優れたソリューションになる可能性があります。 Microsoft はこれらのツールをすべてサポートしていないため、何らかの理由で PsPing と TraceTCP を動作させることができない場合は、Netmon などのツールを使用してネットワーク トレースに移動します。

営業時間前にベースラインを取得し、長時間の使用中に再び実行してから、数時間後にもう一度実行できます。 つまり、最終的には次のようなフォルダー構造が存在する可能性があります。

パフォーマンス データをフォルダーに整理する方法を提示している図。

ファイルの名前付け規則も選択する必要があります。 次に、いくつかの例を示します:

  • Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal

  • Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW

  • Feb_08_2015_2pmEST_PerfBaseline_BADPerf

  • Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf

これを行うにはさまざまな方法がありますが、テスト>で発生している dateTime><形式<を使用することをお勧めします。 これについて勤勉に取り組むと、後で問題のトラブルシューティングを行おうとするときに大いに役立ちます。 その後、「2 月 8 日に 2 つのトレースを取りました。1 つはパフォーマンスが良く、1 つは悪い結果を示したので、比較できます」と言うことができます。 これはトラブルシューティングに役立ちます。

履歴ベースラインを維持するには、整理された方法が必要です。 この例では、単純なメソッドによって 3 つのコマンド ライン出力が生成され、結果がスクリーンショットとして収集されましたが、代わりにネットワーク キャプチャ ファイルが作成されている可能性があります。 最適な方法を使用します。 履歴ベースラインを保存し、オンライン サービスの動作の変化に気付いた時点で参照します。

パイロット中にパフォーマンス データを収集する理由

Office 365 サービスのパイロットの間よりも、ベースラインを作成し始めるのに適した時間はありません。 オフィスには数千人のユーザー、数十万人のユーザー、または 5 人のユーザーがいる場合がありますが、少数のユーザーであっても、テストを実行してパフォーマンスの変動を測定できます。 大企業の場合は、数百人のユーザーがOffice 365をパイロットしている代表的なサンプルを数千人に投影して、問題が発生する前に問題が発生する可能性がある場所を把握できます。

小規模な会社の場合、オンボーディングでは、すべてのユーザーが同時にサービスにアクセスし、パイロットが存在しないという意味で、パフォーマンス測定を維持して、パフォーマンスが低下した操作のトラブルシューティングを行う必要がある可能性のあるすべてのユーザーに表示するデータが得られるようにします。 たとえば、突然、すぐに発生した中規模のグラフィックをアップロードするまでに建物を歩き回ることができます。

ベースラインを収集する方法

すべてのトラブルシューティング 計画では、少なくとも次のことを特定する必要があります。

  • 使用しているクライアント コンピューター (コンピューターまたはデバイスの種類、IP アドレス、および問題の原因となったアクション)

  • クライアント コンピューターが世界に存在する場所 (たとえば、ネットワークへの VPN 上のユーザー、リモートで作業しているユーザー、会社のイントラネット上のユーザーなど)

  • クライアント コンピューターがネットワークから使用するエグレス ポイント (ISP またはインターネットに対してトラフィックがビジネスを離れるポイント)

ネットワークのレイアウトは、ネットワーク管理者から確認できます。 小規模なネットワークにいる場合は、インターネットに接続しているデバイスを見て、レイアウトに関する質問がある場合は ISP に問い合わせてください。 参照用の最終的なレイアウトのグラフィックを作成します。

このセクションは、単純なコマンド ライン ツールとメソッド、およびより高度なツール オプションに分かれています。 最初に簡単なメソッドについて説明します。 ただし、現在パフォーマンスの問題が発生した場合は、高度な方法に進み、サンプルのパフォーマンストラブルシューティング アクション プランを試す必要があります。

単純なメソッド

これらの単純な方法の目的は、時間の経過と共に単純なパフォーマンス ベースラインを取得し、理解し、適切に格納し、Office 365パフォーマンスについて通知できるようにすることです。 前に見てきたように、単純な単純な図を次に示します。

クライアント、プロキシ、クラウドを使用した基本的なネットワークと、PSPing、TraceTCP、およびネットワーク トレースに関するツールの提案。

注:

TraceTCP はこのスクリーン ショットに含まれています。これは、要求の処理にかかる時間 (ミリ秒単位)、1 台のコンピューターから次のコンピューターへのネットワーク ホップまたは接続の数を示すのに便利なツールであるためです。 TraceTCP では、ホップ中に使用されるサーバーの名前を指定することもできます。これは、サポートのMicrosoft Office 365トラブルシューティング ツールに役立ちます。 > TraceTCP コマンドは非常に簡単です。 >tracetcp.exe outlook.office365.com:443> 次のように、コマンドにポート番号を含めてください。 >TraceTCP は無料でダウンロードできますが、Wincap に依存しています。 Wincap は、Netmon でも使用およびインストールされるツールです。 また、高度なメソッドセクションで Netmon を使用します。

複数のオフィスがある場合は、各場所のクライアントから一連のデータを保持する必要があります。 このテストでは待機時間が測定されます。この場合、クライアントが要求をOffice 365に送信してから、要求に応答するまでの時間を表す数値Office 365。 テストはクライアント コンピューター上のドメイン内で行われ、ネットワーク内からエグレス ポイントを経由し、インターネット経由でOffice 365に戻るラウンド トリップを測定します。

エグレス ポイント (この場合はプロキシ サーバー) に対処するには、いくつかの方法があります。 1 から 2、2 から 3 までトレースし、ミリ秒単位で数値を追加して、最終的な合計をネットワークの端に取得できます。 または、Office 365 アドレスのプロキシをバイパスするように接続を構成することもできます。 ファイアウォール、リバース プロキシ、またはその 2 つの組み合わせを備えた大規模なネットワークでは、プロキシ サーバーで例外を作成し、トラフィックが多数の URL を渡せるようにする必要がある場合があります。 Office 365で使用されるエンドポイントの一覧については、「Office 365 URL と IP アドレス範囲」を参照してください。 認証プロキシがある場合は、まず次の例外をテストします。

  • ポート 80 と 443

  • TCP と HTTPs

  • 次のいずれかの URL に送信される接続:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

すべてのユーザーがプロキシの干渉や認証なしでこれらのアドレスにアクセスできるようにする必要があります。 小規模なネットワークでは、Web ブラウザーのプロキシ バイパス リストにこれらを追加する必要があります。

Internet Explorer でプロキシ バイパス リストにこれらを追加するには、[ツール>] インターネット オプション接続>LAN 設定>の [詳細設定] > に移動します。 [詳細設定] タブには、プロキシ サーバーとプロキシ サーバーのポートも表示されます。 [詳細設定] ボタンにアクセスするには、[LAN にプロキシ サーバーを使用する] チェック ボックスをオンにする必要がある場合があります。 ローカル アドレスのプロキシ サーバーのバイパスがオンになっていることを確認します。 [詳細設定] をクリックすると、例外を入力できるテキスト ボックスが表示されます。 上に示したワイルドカード URL をセミコロンで区切ります。次に例を示します。

*.microsoftonline.com;*.sharepoint.com

プロキシをバイパスすると、Office 365 URL で ping または PsPing を直接使用できるようになります。 次の手順では、ping outlook.office365.com をテストします。 または、コマンドにポート番号を指定できる PsPing または別のツールを使用している場合は、psPing を portal.microsoftonline.com:443 して、平均ラウンドトリップ時間をミリ秒単位で確認します。

ラウンドトリップ時間 (RTT) は、outlook.office365.com などのサーバーに HTTP 要求を送信し、サーバーが実行したことを認識する応答を返すのにかかる時間を測定する数値です。 この省略形が RTT と表示されることがあります。 これは比較的短い時間である必要があります。

このテストを行うには、PSPing または、Office 365によってブロックされる ICMP パケットを使用しない別のツールを使用する必要があります。

PsPing を使用して、Office 365 URL から直接ラウンド トリップ時間をミリ秒単位で取得する方法

  1. 次の手順を実行して、管理者特権でのコマンド プロンプトを実行します。

  2. [開始] をクリックします。

  3. [ 検索の開始 ] ボックスに「cmd」と入力し、Ctrl キーを押しながら Shift キーを押しながら Enter キーを押します。

  4. [ユーザー アカウント制御] ダイアログ ボックスが表示された場合、このボックスに希望する動作が表示されていることを確認し、[継続] をクリックします。

  5. ツール (この場合は PsPing) がインストールされているフォルダーに移動し、次のOffice 365 URL をテストします。

  • psping admin.microsoft.com:443

  • psping microsoft-my.sharepoint.com:443

  • psping outlook.office365.com:443

  • psping www.yammer.com:443

    PSPing コマンドは、ポート 443 を microsoft-my.sharepoint.com します。

必ずポート番号 443 を含めます。 Office 365は暗号化されたチャネルで動作することを忘れないでください。 ポート番号を指定せずに PsPing を実行すると、要求は失敗します。 短いリストに ping を実行したら、平均時間 (ミリ秒) を探します。 これは、記録する必要があるものです。

ラウンド トリップ時間が 2.8 ミリ秒の PSPing をプロキシするクライアントの図を示す図。

プロキシ バイパスに慣れていない場合で、ステップ バイ ステップを実行する場合は、まずプロキシ サーバーの名前を確認する必要があります。 Internet Explorer の [ツール>] インターネット オプション接続>LAN 設定>の[詳細設定] > に移動します。 [詳細設定] タブには、プロキシ サーバーが一覧表示されます。 次のタスクを完了して、コマンド プロンプトでそのプロキシ サーバーに ping を実行します。

プロキシ サーバーに ping を実行し、ステージ 1 からステージ 2 のラウンド トリップ値をミリ秒単位で取得するには

  1. 次の手順を実行して、管理者特権でのコマンド プロンプトを実行します。

  2. [開始] をクリックします。

  3. [ 検索の開始 ] ボックスに「cmd」と入力し、Ctrl キーを押しながら Shift キーを押しながら Enter キーを押します。

  4. [ユーザー アカウント制御] ダイアログ ボックスが表示された場合、このボックスに希望する動作が表示されていることを確認し、[継続] をクリックします。

  5. ブラウザーが使用するプロキシ サーバーの名前、またはプロキシ サーバーの IP アドレスに ping <を入力し、Enter キーを> 押します。 PsPing またはその他のツールがインストールされている場合は、代わりにそのツールを使用することを選択できます。

    コマンドは、次のいずれかの例のようになります。

  • ping ourproxy.ourdomain.industry.business.com

  • ping 155.55.121.55

  • ping ourproxy

  • psping ourproxy.ourdomain.industry.business.com:80

  • psping 155.55.121.55:80

  • psping ourproxy:80

  1. トレースがテスト パケットの送信を停止すると、平均をミリ秒単位で示す小さな概要が得られます。これは後の値です。 プロンプトのスクリーンショットを撮り、名前付け規則を使用して保存します。 この時点で、ダイアグラムに値を入力することもできます。

おそらく、あなたは早い段階でトレースを取得し、クライアントはプロキシ (またはインターネットに出るエグレス サーバー) にすばやくアクセスできます。 この場合、数値は次のようになります。

クライアントからプロキシまでのラウンド トリップ時間が 2.8 ミリ秒であることを示す図。

クライアント コンピューターがプロキシ (またはエグレス) サーバーにアクセスできる少数のクライアント コンピューターの 1 つである場合は、そのコンピューターにリモートで接続し、そこから Office 365 URL に PsPing にコマンド プロンプトを実行することで、テストの次の手順を実行できます。 そのコンピューターにアクセスできない場合は、ネットワーク リソースに連絡して、次の手順に関するヘルプを確認し、そのように正確な番号を取得できます。 それが不可能な場合は、問題のOffice 365 URL に対して PsPing を取得し、プロキシ サーバーに対する PsPing または Ping 時間と比較します。

たとえば、クライアントから Office 365 URL まで 51.84 ミリ秒で、クライアントからプロキシ (またはエグレス ポイント) までの時間が 2.8 ミリ秒の場合、エグレスからOffice 365までの時間は 49.04 ミリ秒です。 同様に、1 日の高さの間にクライアントからプロキシに 12.25 ミリ秒、クライアントから Office 365 URL まで 62.01 ミリ秒の PsPing がある場合、プロキシのOffice 365 URL への送信の平均値は 49.76 ミリ秒です。

値を減算できるように、クライアントからクライアントの横にあるプロキシからOffice 365への ping をミリ秒単位で示す追加の図。

トラブルシューティングの面では、これらのベースラインを維持するだけで興味深いものが見つかる場合があります。 たとえば、プロキシまたはエグレス ポイントから Office 365 URL までの待機時間が一般に約 40 ミリ秒から 59 ミリ秒で、クライアントからプロキシまたはエグレス ポイントまでの待機時間が約 3 ミリ秒から 7 ミリ秒である場合 (その時間帯に表示されるネットワーク トラフィックの量に応じて) が発生すると、プロキシまたはエグレス のベースラインに最後の 3 つのクライアントが表示された場合に問題が発生することがわかります。待機時間は 45 ミリ秒です。

高度なメソッド

Office 365に対するインターネット要求で何が起こっているかを本当に知りたい場合は、ネットワーク トレースについて理解する必要があります。 これらのトレースにどのツールを使用するかは関係ありません。HTTPWatch、Netmon、Message Analyzer、Wireshark、Fiddler、Developer Dashboard ツール、またはその他のツールがネットワーク トラフィックをキャプチャしてフィルター処理できる限り、そのツールが実行します。 このセクションでは、問題の全体像を把握するために、これらのツールの 1 つ以上を実行することが有益であることがわかります。 テストする場合、これらのツールの一部は、独自のプロキシとしても機能します。 付属の記事、Office 365のパフォーマンストラブルシューティング プランで使用されるツールには、Netmon 3.4HTTPWatchまたは WireShark が含まれます。

パフォーマンス ベースラインを取ることは、このメソッドの単純な部分であり、多くの手順はパフォーマンスの問題のトラブルシューティング時と同じです。 パフォーマンスのベースラインを作成するより高度な方法では、ネットワーク トレースを取得して格納する必要があります。 この記事のほとんどの例では SharePoint Online を使用していますが、テストと記録をサブスクライブするOffice 365 サービス全体で一般的なアクションの一覧を作成する必要があります。 ベースラインの例を次に示します。

  • SPO のベースライン 一覧 - ** 手順 1: ** SPO Web サイトのホーム ページを参照し、ネットワーク トレースを実行します。 トレースを保存します。

  • SPO のベースライン リスト - 手順 2: Enterprise Search を使用して用語 (会社名など) を検索し、ネットワーク トレースを実行します。 トレースを保存します。

  • SPO のベースライン 一覧 - 手順 3: SharePoint Online ドキュメント ライブラリに大きなファイルをアップロードし、ネットワーク トレースを実行します。 トレースを保存します。

  • SPO のベースライン リスト - 手順 4: OneDrive Web サイトのホーム ページを参照し、ネットワーク トレースを実行します。 トレースを保存します。

この一覧には、ユーザーが SharePoint Online に対して実行する最も重要な一般的なアクションが含まれている必要があります。 最後の手順では、OneDrive for Businessを追跡するために、SharePoint Online ホーム ページの読み込みと (多くの場合、企業によってカスタマイズされる) と、カスタマイズされることの少ないOneDrive for Businessホーム ページの負荷の比較が組み込まれています。 これは、読み込みの遅い SharePoint Online サイトに関する基本的なテストです。 この違いの記録をテストに組み込むことができます。

パフォーマンスの問題の真っ最中の場合、多くの手順はベースラインを実行する場合と同じです。 ネットワーク トレースは重要になるため、次に重要なトレースを取得する 方法 を処理します。

パフォーマンスの問題に対処するには、 パフォーマンスの問題が発生した時点でトレースを作成する必要があります。 ログを収集するための適切なツールを用意する必要があり、可能な限り最適な情報を収集するために実行するトラブルシューティング アクションの一覧であるアクション プランが必要です。 最初に行うには、テストの日時を記録して、タイミングを反映したフォルダーにファイルを保存できるようにします。 次に、問題の手順自体に絞り込みます。 これらは、テストに使用する正確な手順です。 基本的な点を忘れないでください。問題が Outlook だけの場合は、問題の動作が 1 つのOffice 365 サービスでのみ発生することを記録してください。 この問題の範囲を絞り込むと、解決できるものに集中できます。

関連項目

Office 365 エンドポイントの管理