使用基準與效能歷程記錄調整 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效能是服務問題的犧牲者。

[Office 365健全狀況] 儀表板，所有工作負載都顯示綠色，但 Exchange 除外，其中顯示 [服務已還原]。

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

Office 365健康情況儀表板的圖片，說明Exchange Online服務已還原，以及原因。

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

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

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

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

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

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

如何定義和測試效能問題

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

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

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

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

  • 不清楚如何在收件匣和行事曆之間切換，以在膝上型電腦上採取行動。

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

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

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

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

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

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

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

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

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

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

  • 您位於世界何處？

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

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

具有用戶端、Proxy 和雲端的基本網路，以及 PSPing、TraceTCP 和網路追蹤的工具建議。

這些選項會列為 [簡單 ] 和 [ 進階 ]，因為您需要具備大量專業知識，才能尋找效能資料。 相較于執行 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。 為您的參考建立最終版面配置的圖形。

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

簡單方法

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

具有用戶端、Proxy 和雲端的基本網路，以及 PSPing、TraceTCP 和網路追蹤的工具建議。

注意事項

TraceTCP 包含在此螢幕擷取畫面中，因為它是實用的工具，可讓您以毫秒為單位來顯示要求需要多少時間來處理，以及要求到達目的地所需的網路躍點或從一部電腦到下一部電腦的連線數目。 TraceTCP 也可以提供在躍點期間使用的伺服器名稱，這對支援中的Microsoft Office 365疑難排解員很有用。 >TraceTCP 命令可能非常簡單，例如： >tracetcp.exe outlook.office365.com:443> 請記得在命令中包含埠號碼！ >TraceTCP 是免費下載，但依賴 Wincap。 Wincap 是一種工具，也會由 Netmon 使用及安裝。 我們也會在 [進階方法] 區段中使用 Netmon。

如果您有多個辦公室，您也必須在每個位置保留用戶端的一組資料。 此測試會測量延遲，在此情況下，這是一個數位值，描述用戶端傳送要求至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 的連線：

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

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

若要將這些新增至 Internet Explorer 中的 Proxy 略過清單，請移至[工具>][網際網路選項>聯> 機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

    PSPing 命令會移至 microsoft-my.sharepoint.com 埠 443。

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

此圖顯示用戶端至 Proxy PSPing 的圖例，其來回時間為 2.8 毫秒。

如果您不熟悉 Proxy 略過，而且想要逐步執行，則必須先找出 Proxy 伺服器的名稱。 在 Internet Explorer 中，移至[工具>] [網際網路選項>] [聯>機 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

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

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

顯示從用戶端到 Proxy 2.8 毫秒之來回時間的圖形。

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

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

顯示從用戶端到用戶端旁邊 Proxy 以毫秒為單位 ping 的其他圖形，以Office 365讓值可以被減去。

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

進階方法

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

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

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

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

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

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

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

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

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

另請參閱

管理 Office 365 端點