使用基準與效能歷程記錄調整 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 中的服務事件不同。 以下說明如何區分這些資訊。

服務事件會在 Office 365 服務本身發生問題時發生。 您可能會在 Microsoft 365 系統管理中心 的 [目前健康情況] 下看到紅色或黃色圖示。 您可能會注意到連線到 Office 365的用戶端電腦效能緩慢。 例如，如果目前的健全狀況報告紅色圖示，而且您在 Exchange 旁邊看到 [調查]，您可能會收到組織中抱怨用戶端信箱使用 Exchange Online 速度緩慢的人員來電。 在此情況下，合理假設您的 Exchange Online 效能是服務問題的犧牲者。

此時，Office 365 系統管理員應該檢查 [目前的健康情況]，然後檢視詳細數據和歷程記錄，以隨時掌握系統的維護最新情況。 目前的健全狀況儀錶板是針對服務的變更和問題更新您。 寫入健康情況歷程記錄、系統管理員至系統管理員的附註和說明，可協助您量測，並讓您隨時掌握進行中工作的相關信息。

效能問題不是服務事件，即使事件可能會導致效能變慢。 效能問題看起來像這樣：

• 無論系統管理中心 目前為 服務報告的健全狀況為何，都發生效能問題。

• 用來進行流程的行為需要很長的時間才能完成或永不完成。

• 您也可以復寫問題，或知道如果您執行一系列正確的步驟，就會發生此問題。

• 如果問題間歇性發生，仍可有模式。 例如，您知道在上午 10：00 前，您會有無法隨時存取 Office 365 的用戶來電。 通話將在中午左右結束。

此清單聽起來可能很熟悉;可能太熟悉。 一旦您知道這是效能問題，問題就會變成「您接下來該怎麼做？」本文的其餘部分可協助您確切判斷。

如何定義和測試效能問題

效能問題通常會隨著時間而出現，因此定義實際問題可能很困難。 Create 問題內容的概念是不錯的問題陳述，然後您需要重複的測試步驟。 以下是問題語句的一些範例，但未提供足夠的資訊：

• 從 [收件匣] 切換到 [行事曆] 過去是未注意到的，現在是咖啡廳。 您可以讓它如同過去一樣執行嗎？

• 將我的檔案上傳至 SharePoint 會永遠耗費時間。 為什麼下午速度很慢，但任何其他時間都很快？ 不能只是快速嗎？

上述問題語句會造成數項大型挑戰。 具體而言，要處理的模棱兩可太多。 例如：

• 不清楚如何在收件匣和行事歷之間切換，以在膝上型計算機上採取行動。

• 當使用者說「不能只是快速」時，什麼是「快速」？

• 「永久」多久？ 這是幾秒嗎？ 還是多分鐘？ 或者，使用者是否可以午餐，而動作會在用戶回來 10 分鐘後完成？

系統管理員和疑難解答員無法從這類一般語句了解問題的 詳細 數據。 例如，他們不知道問題何時開始發生。 疑難解答員可能不知道使用者在家工作，而且只會在其家庭網路上看到緩慢的切換。 或者，使用者會在本機用戶端上執行其他 RAM 密集型應用程式。 系統管理員可能不知道使用者正在執行較舊的操作系統，或尚未執行最近的更新。

當使用者回報效能問題時，需要收集許多資訊。 取得和錄製資訊稱為界定問題範圍。 以下是您可以用來收集效能問題相關信息的基本範圍清單。 這份清單並不詳盡，但可從下列位置開始：

• 問題發生日期為何，以及每天或晚上的哪個時間？

• 您使用何種用戶端計算機，以及它如何連線到商務網路 (VPN、有線、無線) ？

• 您是從遠端工作，還是在辦公室工作？

• 您是否在另一部計算機上嘗試相同的動作，並看到相同的行為？

• 逐步解說讓您遇到問題的步驟，以便撰寫您採取的動作。

• 效能以秒或分鐘為單位的速度有多慢？

• 您位於世界何處？

其中一些問題比其他問題更明顯。 大部分的每個人都會瞭解疑難解答員需要確切的步驟來重現問題。 畢竟，您還可以如何記錄錯誤，以及如何測試問題是否已修正？ 較不明顯的情況包括「您看到問題的日期和時間為何？」，以及「您位於世界何處？」等可同時使用的資訊。 視使用者的運作時間而定，數小時的時間差異可能表示公司網路部分的維護已在進行中。 例如，您的公司有混合式實作，例如混合式 SharePoint 搜尋，可查詢 Microsoft 365 和內部部署 SharePoint Server 2013 實例中 SharePoint 中的搜尋索引，更新可能會在內部部署伺服器數組中進行。 如果您的公司全都在雲端，系統維護可能包括新增或移除網路硬體、推出全公司的更新，或變更 DNS 或其他核心基礎結構。

當您針對效能問題進行疑難解答時，這有點像犯罪場景，您需要精確且觀察，才能從辨識項中得出任何結論。 若要這樣做，您必須藉由收集辨識項來取得良好的問題陳述。 它應該包含計算機的內容、使用者的內容、問題開始時，以及公開效能問題的確切步驟。 此問題陳述應該是您筆記中最上層的頁面，並保持在最上方。 在您處理解決方案之後再次逐步解說問題陳述，您將採取這些步驟來測試並證明您採取的動作是否已解決問題。 這對於瞭解您的工作何時完成非常重要。

您知道效能在良好時的顯示方式嗎？

如果您不知情，沒有人知道。 沒有人有數位。 這表示沒有人可以回答簡單的問題：「關於用來在 Office 365 中顯示收件匣需要多少秒？」，或「主管有 Lync Online 會議時，過去需要多久時間？」，這是許多公司的常見案例。

此處缺少的是效能基準。

基準可為您提供效能的內容。 您應該根據公司的需求，偶爾採取基準。 如果您是較大型的公司，您的營運小組可能會為您的內部部署環境採取基準。 例如，如果您在當月的第一個星期一修補所有 Exchange 伺服器，並在第三個星期一修補所有 SharePoint 伺服器，則 Operations 小組可能會有一份工作清單，以及在修補後執行的案例清單，以證明重要的功能可運作。 例如，開啟 [收件匣]、單擊 [傳送/接收]，並確定資料夾已更新，或在SharePoint 中瀏覽網站的主頁面、進入企業 搜尋 頁面，以及執行會傳回結果的搜尋。

如果您的應用程式處於 Office 365 狀態，您可以測量從網路內的用戶端電腦到輸出點，或離開網路並移至 Office 365 的毫秒) 時間 (一些最基本的基準。 以下是您可以調查和記錄的一些實用基準：

• 識別用戶端電腦與輸出點之間的裝置，例如 Proxy 伺服器。

  • 您必須知道您的裝置，讓您有內容 (IP位址、裝置類型，例如發生效能問題的cetera) 。

  • Proxy 伺服器是常見的輸出點，因此您可以檢查網頁瀏覽器，以查看它設定為使用哪部 Proxy 伺服器，如果有的話。

  • 有第三方工具可以探索和對應您的網路，但了解裝置最安全的方式是詢問網路小組的成員。

• 識別您的因特網服務提供者 (ISP) 、記下其連絡資訊，並詢問您有多少線路頻寬。

• 在公司內部，識別客戶端與輸出點之間裝置的資源，或識別緊急聯繫人以洽詢網路問題。

以下是使用工具進行簡單測試可為您計算的一些基準：

• 從用戶端電腦到輸出點的時間，以毫秒為單位

• 從輸出點到 Office 365 毫秒的時間

• 在流覽時解析 Office 365 URL 之伺服器世界中的位置

• ISP DNS 解析的速度，以毫秒為單位，封包抵達 (網路抖動) 、上傳和下載時間不一致，以毫秒為單位

如果您不熟悉如何執行這些步驟，我們將在本文中詳細說明。

什麼是基準？

當情況變差時，您會知道其影響，但如果您不知道歷程記錄效能數據，就不可能有其可能變得有多糟的內容，以及何時發生。 因此，如果沒有基準，您會遺漏解決拼圖的關鍵線索：拼圖方塊上的圖片。 在效能疑難解答中，您需要 比較點。 不難採用簡單的效能基準。 您的作業小組可以負責依排程執行這些作業。 例如，假設您的連線看起來像這樣：

這表示您已與網路小組聯繫，並發現您已透過 Proxy 伺服器離開公司進行因特網，且該 Proxy 會處理用戶端電腦傳送至雲端的所有要求。 在此情況下，您應該繪製簡化的連線版本，以列出所有插入的裝置。 現在，插入工具，讓您用來測試客戶端、輸出點 (您離開因特網) 的網路，以及 Office 365 雲端之間的效能。

這些選項會列為 [簡單 ] 和 [ 進階 ]，因為您需要具備大量專業知識，才能尋找效能數據。 相較於執行 PsPing 和 TraceTCP 等命令行工具，網路追蹤需要很多時間。 之所以選擇這兩個命令行工具，是因為它們不會使用ICMP封包，這會被 Office 365 封鎖，因為它們會提供離開客戶端電腦所需的毫秒時間，或者如果您有存取) 並抵達 Office 365，則會 (Proxy 伺服器。 從一部計算機到另一部計算機的每個個別躍點最後都會有時間值，這非常適合基準！ 同樣重要的是，這些命令行工具可讓您將埠號碼新增至命令，因為 Office 365 透過埠 443 進行通訊，這是安全套接字層和傳輸層安全性 (SSL 和 TLS) 所使用的埠。 不過，其他第三方工具可能是更適合您情況的解決方案。 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 日追蹤了兩個追蹤，一個顯示效能良好，另一個顯示不正確，因此我們可以比較它們」。 這有助於進行疑難解答。

您需要有組織的方式來保留歷史基準。 在此範例中，簡單方法會產生三個命令行輸出，並將結果收集為螢幕快照，但您可能會改用網路擷取檔案。 使用最適合您的方法。 儲存歷程記錄基準，並在您注意到 線上服務 的行為變更時參考它們。

為何要在試驗期間收集效能數據？

沒有比起試驗 Office 365 服務更好的時間開始建立基準。 您的辦公室可能有數千位使用者、數十萬名使用者，或可能有五位使用者，但即使有少數使用者，您也可以執行測試來測量效能的波動。 如果是大型公司，數百名試驗 Office 365 使用者的代表性範例可以向外投影到數千人，讓您知道問題發生之前可能發生的問題。

如果是小型公司，其中上線表示所有用戶同時移至服務，而且沒有試驗，請保留效能量值，讓您能夠向可能必須針對效能不佳的作業進行疑難解答的任何人顯示數據。 例如，如果您注意到您突然可以在上傳中型圖形所花費的時間內，在建置中快速進行。

如何收集基準

針對所有疑難解答計劃，您至少需要識別下列專案：

• 您使用的用戶端電腦 (計算機或裝置的類型、IP 位址，以及造成問題的動作)

• 例如，用戶端電腦位於世界 (，不論此使用者是透過 VPN 連線到網路、從遠端工作，還是在公司內部網路上)

• 用戶端電腦從您的網路使用的輸出點 (流量離開 ISP 或因特網)

您可以從網路管理員找出網路的配置。 如果您是在小型網路上，請查看連線到因特網的裝置，如果您有配置的相關問題，請呼叫 ISP。 Create 參考的最終版面配置圖形。

本節分成簡單的命令行工具和方法，以及更進階的工具選項。 我們會先討論簡單的方法。 但是，如果您目前遇到效能問題，您應該跳到進階方法，並嘗試範例效能疑難解答行動計劃。

簡單方法

這些簡單方法的目標是要瞭解如何採用、瞭解及正確儲存一段時間的簡單效能基準，讓您瞭解 Office 365 效能。 以下是簡單的簡單圖表，如您先前所見：

如果您有多個辦公室，您也必須在每個位置保留用戶端的一組數據。 此測試會測量延遲，在此情況下，這是一個數位值，描述用戶端傳送要求至 Office 365，以及 Office 365 回應要求之間的時間量。 測試會源自用戶端電腦上的網域內部，並尋找從網路內部、經由輸出點、經由因特網到 Office 365 及返回的來回行程。

有數種方式可以處理輸出點，在此案例中為 Proxy 伺服器。 您可以追蹤 1 到 2，然後追蹤 2 到 3，然後以毫秒為單位新增數位，以取得網路邊緣的最終總計。 或者，您可以將連線設定為略過 Office 365 位址的 Proxy。 在具有防火牆、反向 Proxy 或兩者組合的較大網路中，您可能需要在 Proxy 伺服器上進行例外狀況，以允許流量通過大量 URL。 如需 Office 365 使用的端點清單，請參閱 Office 365 URL 和 IP 位址範圍。 如果您有驗證 Proxy，請先測試下列專案的例外狀況：

• 連接埠 80 和 443

• TCP 和 HTTP

• 輸出至下列任何 URL 的 Connections：

• *.microsoftonline.com

• *.microsoftonline-p.com

• *.sharepoint.com

• *.outlook.com

• *.lync.com

• osub.microsoft.com

所有用戶都必須能夠存取這些位址，而不需要任何 Proxy 干擾或驗證。 在較小的網路上，您應該將這些新增至網頁瀏覽器中的 Proxy 略過清單。

若要將這些專案新增至 Internet Explorer 中的 Proxy 略過清單，請移至 [工具>][因特網選項>Connections>LAN 設定>[進階]。 進階索引標籤也是您找到 Proxy 伺服器和 Proxy 伺服器埠的位置。 您可能需要選取 [ 使用適用於 LAN 的 Proxy 伺服器] 複選框，才能存取 [ 進階 ] 按鈕。 您會想要確定已檢查本機 位址的略過 Proxy 伺服器 。 選取 [ 進階] 之後，您會看到一個文本框，您可以在其中輸入例外狀況。 以分號分隔上面所列的通配符 URL，例如：

*.microsoftonline.com;*.sharepoint.com

略過 Proxy 之後，您應該能夠直接在 Office 365 URL 上使用 ping 或 PsPing。 下一個步驟是測試 ping outlook.office365.com。 或者，如果您使用 PsPing 或其他可讓您提供埠號碼給命令的工具，請針對 portal.microsoftonline.com:443 使用 PsPing 來查看以毫秒為單位的平均來回時間。

來回時間或 RTT 是一個數位值，可測量將 HTTP 要求傳送至伺服器所需的時間，例如 outlook.office365.com，並取得回應以確認伺服器知道您已這麼做。 您有時會看到此縮寫為 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

  

請務必包含埠號碼 443。 請記住，Office 365 在加密的通道上運作。 如果您沒有埠號碼的 PsPing，您的要求將會失敗。 偵測簡短清單之後，請尋找毫秒的平均時間 (毫秒) 。 這就是您想要記錄的內容！

如果您不熟悉 Proxy 略過，而且想要逐步執行，則必須先找出 Proxy 伺服器的名稱。 在 Internet Explorer 中，移至 [工具>] [因特網選項>Connections>[LAN 設定>][進階]。 [ 進階 ] 索引標籤是您會看到列出 Proxy 伺服器的位置。 在命令提示字元中完成此工作，以 Ping 該 Proxy 伺服器：

偵測 Proxy 伺服器並取得階段 1 到 2 以毫秒為單位的來回值

1. 完成下列步驟來執行提升權限的命令提示字元：

2. 按一下 [開始]。

3. 在 [開始 搜尋] 方塊中，輸入 cmd，然後按 CTRL+SHIFT+ENTER。

4. 如果 [ 用戶帳戶控制] 對話框出現，請確認其顯示的動作是您想要的動作，然後按兩下 [ 繼續]。

5. 輸入 ping <瀏覽器所使用的 Proxy 伺服器名稱，或 Proxy 伺服器> 的 IP 位址，然後按 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

3. 當追蹤停止傳送測試封包時，您會收到一個小型摘要，其中列出平均值，以毫秒為單位，也就是您所追蹤的值。 擷取提示的螢幕快照，並使用您的命名慣例儲存它。 此時，它也有助於填入圖表中的 值。

也許您已在一大早進行追蹤，而您的用戶端可以快速進入 Proxy (或任何輸出伺服器結束至因特網) 。 在此情況下，您的數位可能如下所示：

如果您的用戶端電腦是可存取 Proxy (或輸出) 伺服器的少數部分之一，您可以從遠端連線到該電腦，執行命令提示字元以從該處對 Office 365 URL 執行測試的下一個回合。 如果您沒有該電腦的存取權，您可以連絡網路資源以取得下一個回合的協助，並以這種方式取得確切的數位。 如果無法這麼做，請針對有問題的 Office 365 URL 取得 PsPing，並將其與 Proxy 伺服器的 PsPing 或 Ping 時間進行比較。

例如，如果您有 51.84 毫秒從用戶端到 Office 365 URL，而且您有 2.8 毫秒從用戶端到 Proxy (或輸出點) ，則您有 49.04 毫秒從輸出到 Office 365。 同樣地，如果您在一天的高度期間，從用戶端到 Proxy 的 PsPing 為 12.25 毫秒，而從用戶端到 Office 365 URL 的 62.01 毫秒，則 Proxy 輸出至 Office 365 URL 的平均值為 49.76 毫秒。

就疑難解答而言，您可能會發現一些有趣的專案，只是保留這些基準。 例如，如果您發現從 Proxy 或輸出點到 Office 365 URL 的延遲通常約為 40 毫秒到 59 毫秒， 並且讓用戶端對 Proxy 或輸出點延遲約 3 毫秒到 7 毫秒， (視您在一天當中的該時間看到的網路流量量而定) 然後您會知道，如果最後三個用戶端要 Proxy 或輸出基準，會有問題顯示 45 毫秒的延遲。

進階方法

如果您真的想要知道因特網要求 Office 365 發生什麼情況，您必須熟悉網路追蹤。 只要該工具可以擷取和篩選網路流量，您偏好哪些工具進行這些追蹤、HTTPWatch、Netmon、Message Analyzer、Wireshark、Fiddler、開發人員儀錶板工具或任何其他工具都無關緊要。 您會在本節中看到執行其中一個以上的工具，以更完整地了解問題。 當您進行測試時，其中一些工具也會以自己的方式做為 Proxy。 隨附文章中使用的工具：適用於 Office 365 的效能疑難解答計劃，包括 Netmon 3.4、HTTPWatch 或 WireShark。

採用效能基準是這個方法的簡單部分，而且許多步驟都與針對效能問題進行疑難解答時相同。 建立效能基準的更進階方法需要您擷取和儲存網路追蹤。 本文中的大部分範例都使用 SharePoint，但您應該針對您訂閱測試和記錄的 Office 365 服務開發一份通用動作清單。 以下是基準範例：

• SPO 的基準清單 - ** 步驟 1： ** 流覽 SPO 網站的首頁並執行網路追蹤。 儲存追蹤。

• SPO 的基準清單 - 步驟 2：搜尋 一個字詞 (，例如透過企業 搜尋) 公司名稱，並執行網路追蹤。 儲存追蹤。

• SPO 的基準清單 - 步驟 3： 將大型檔案上傳至 SharePoint 文檔庫並執行網路追蹤。 儲存追蹤。

• SPO 的基準清單 - 步驟 4： 流覽 OneDrive 網站的首頁並執行網路追蹤。 儲存追蹤。

此清單應包含使用者對 SharePoint 採取的最重要常見動作。 請注意，最後一個步驟若要追蹤至 OneDrive，請建置 SharePoint 首頁 (負載之間的比較，這通常由公司) 和 OneDrive 首頁自定義，這是很少自定義的。 這是 SharePoint 網站載入緩慢時的基本測試。 您可以在測試中建立此差異的記錄。

如果您遇到效能問題，許多步驟都與採用基準時相同。 網路追蹤變得非常重要，因此我們將處理下一步 要採取 重要追蹤的方式。

若要解決效能問題， 您現在必須在遇到效能問題時進行追蹤。 您必須擁有適當的工具來收集記錄，而且您需要一個行動計劃，也就是要採取的疑難解答動作清單，以收集您所能取得的最佳資訊。 第一件事是記錄測試的日期和時間，以便將檔案儲存在反映時間的資料夾中。 接下來，縮小至問題步驟本身。 這些是您將用於測試的確切步驟。 別忘了基本概念：如果問題僅適用於 Outlook，請務必記錄問題行為只發生在一個 Office 365 服務中。 縮小此問題的範圍可協助您專注於可以解決的專案。

另請參閱

管理 Office 365 端點