使用基準與效能歷程記錄調整 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 支援開啟案例的情況前,可以先收集資料,並採取探索且可能解決問題的動作。

重要: 請注意 Office 365 中的容量規劃和限制。這些資訊可在您嘗試解決效能問題時,完成適當的前置工作。這裡是 Office 365 平台服務描述的連結。這是中心樞紐,Office 365 提供的所有服務都具有移至其專屬服務描述的連結,而這些描述的內容皆源自這裡。這表示,例如,您需要查看 SharePoint Online 的標準限制時,您要按一下 SharePoint Online 服務描述,並找到其<SharePoint Online 限制>一節

在您進行疑難排解時,請確定您了解效能會隨情況而改變;效能並非一旦達到理想值即可永久停留在該水準 (若您相信事實並非如此,那麼許多使用者同時上線、或進行大量資料移轉等偶發的高頻寬工作,將會帶來極大的壓力,請針對那些的情況對效能所產生的影響進行規劃)。您可以 (而且應該) 概略了解效能目標,但許多變數都會影響效能,因此效能會有所變化。這是效能的本質。

效能疑難排解不是為了要達成特定目標並永久維持這些數據,而是要根據所有變數來改善現有活動。

如何以外觀判斷效能問題呢?

首先,您必須確定您遇到的是效能問題,而不是服務事件。Office 365 中的服務事件與效能問題不同。以下是分辨兩者的方法。

如果 Office 365 服務有問題,這就是服務事件。您會在 Office 365 系統管理中心的 [目前健康情況] 底下看到紅色或黃色圖示,您可能也會在連線至 Office 365 的用戶端電腦上發現效能變慢的情形。例如,如果目前健康情況報告為紅色圖示,而且您在 Exchange 旁看到 [調查],那麼可能會有組織內部人員抱怨使用 Exchange Online 的用戶端信箱效能不彰。在這種情況下,可合理假設您的 Exchange Online 效能剛好反映服務有問題。

Office 365 健康情況儀表板中所有工作負載均顯示為綠色,除了 Exchange 以外,其顯示為 [服務已還原]。

此時,您身為 Office 365 系統管理員,應經常檢查 [目前健康情況] 及 [檢視詳細資料和歷程記錄],將我們在系統上執行的維護保持於最新狀態。[目前健康情況] 儀表板可讓您了解服務的相關變更及其中的問題。由各個管理員寫入健康情況歷程記錄的筆記及說明,可協助您判斷您的影響,並掌握進行中工作的相關資訊。

Office 365 健康情況儀表板圖片,其中說明 Exchange Online 服務已還原及原因。

雖然事件也會造成效能緩慢,但效能問題並不是服務事件。效能問題看起來像這樣:

  • 無論 Office 365 系統管理中心 [目前健康情況] 針對服務報告哪些內容,都仍會發生效能問題。

  • 以往非常順暢的行為,現在卻耗費很長時間完成或永遠無法完成。

  • 您也可以重現問題,或至少知道當您執行一系列的適當步驟時會發生相關情況。

  • 如果問題是間歇性發生,表示有模式可循。例如,您知道上午 10 點前使用者會來電表示無法確實存取 Office 365,但這類來電接近正午時會減少。

這可能聽起來很熟悉,或許您曾經遇過這樣的情況。知道是效能問題後,您應該轉而思考「下一步該做什麼」。本文其餘部分可協助您準確地判斷後續步驟。

如何定義和測試效能問題

效能問題通常會隨時間而出現,因此可能不太容易定義實際發生的問題。您需要建立詳實的問題陳述、充分了解問題內容,然後產生可重複的測試步驟來解決問題。否則,儘管錯不在您,您還是可能失敗。為什麼?下列是未提供足夠資訊的問題陳述範例:

  • 從我的收件匣切換到行事曆時發生了一些事,我沒多加留意,而現在是休息時間。您可以讓它跟之前一樣嗎?

  • 我的檔案上傳到 SharePoint Online 的速度超慢。為什麼下午很慢,但其他任何時間就很快?不能再快一點嗎?

上述問題陳述帶來數項大挑戰。具體而言,有許多不明確的事項待處理。例如:

  • 不清楚先前在膝上型電腦的 [收件匣] 和 [行事曆] 之間切換時的反應為何。

  • 當使用者說:「它不能快一點嗎?」,怎麼樣才叫「快」?

  • 多久是「永無止境」? 是指幾秒鐘、幾分鐘,或使用者去吃午餐回來後的十分鐘內完成?

所有這一切並沒有考慮到系統管理員和疑難排解員無法從下列這類問題陳述了解許多細節。例如,問題開始發生時;使用者在家中工作,因此只有在家用網路上時看到切換速度變慢;使用者必須在本機用戶端上執行數個其他 RAM 密集型應用程式,或是使用者執行舊版作業系統,或未執行最新的更新。

當使用者報告效能問題時,需要收集許多資訊。收集資訊的這項動作,屬於「界定問題的範圍」或進行調查的一部分。下列是基本的界定範圍清單,可讓您用來收集效能問題的相關資訊。這份清單並不完整,但您可由此開始製作自己的清單:

  • 在哪一天發生問題,並且是在白天或晚上的何時發生?

  • 您之前使用什麼類型的用戶端電腦,以及如何連線至企業網路 (VPN、有線、無線)?

  • 您從遠端或是在辦公室中工作?

  • 您曾嘗試在另一部電腦上執行相同的動作,而且看到相同的行為?

  • 逐步執行產生問題的步驟,以便您寫下您所採取的動作。

  • 緩慢的效能是指幾秒鐘或幾分鐘?

  • 您位於全世界的哪個位置?

其中有些問題比其他問題更加明顯。幾乎每個人都了解疑難排解員需要知道確切步驟以重現問題。最後您還能針對出現的問題記錄哪些資訊,以及可以進行哪些測試以確認已修正此問題?您容易忽略可串聯使用的資訊,例如「您看到問題的日期和時間為何?」和「您位於世界的哪個位置?」。根據使用者當時的工作時間,幾小時的時間差可能表示您公司的部分網路已經在進行維護。例如,若貴公司採取混合式實作 (比方說可同時在 SharePoint Online 和內部部署的 SharePoint Server 2013 執行個體中查詢搜尋索引的混合式 SharePoint 搜尋),則可能會在內部伺服器陣列中進行更新。如果貴公司的所有資料都放在雲端,系統維護可能包括新增或移除網路硬體、在全公司發行更新,或是對 DNS 或其他核心基礎結構進行變更。

疑難排解效能問題時,有點類似犯罪現場,您必須精確細心地繪製證據的任何部分。若要這樣做,您必須收集證據以取得詳實的問題陳述。您收集的資料應該包含電腦內容、使用者內容,以及造成效能問題的確切步驟。此問題陳述應保留在您的筆記中的最上層頁面。採行解決方案之後,您可再次查閱問題陳述,亦即執行步驟以測試並證明您採取的動作已解決問題。這是了解您已完成工作的關鍵。

您如何得知效能卓越?

若不幸的話,則沒有人知道。沒有人擁有數據。這表示沒有人可以針對許多公司的常見情況回答下列這類簡單問題:「之前在 Office 365 中叫出收件匣約需幾秒鐘?」或「之前高階主管進行 Lync Online 會議約需多少時間?」。

這裡所缺少的資訊是效能比較基準

比較基準可讓您了解效能的內容。公司的需求會決定您應該偶爾或經常執行比較基準。如果您身處較大規模的公司,則營運團隊可能已為內部部署環境執行比較基準。例如,如果您在每月的第一個星期一修補所有 Exchange 伺服器,在第三個星期一修補所有 SharePoint 伺服器,您的作業團隊可能有一份工作和案例清單可執行後置修補,以證明重要功能可運作。例如,開啟收件匣、按一下 [傳送/接收],然後確定資料夾更新,或是在 SharePoint 中瀏覽網站的主頁面、進入企業搜尋頁面,並搜尋傳回結果。

如果您的應用程式位於 Office 365 中,您可執行的一些常見比較基準會 (以毫秒為單位) 測量從網路內部的用戶端電腦到「出口端點」或您離開網路並前往 Office 365 的位置所需的時間量。以下是您可以調查與記錄的幾項實用比較基準:

  • 識別用戶端電腦與 Proxy 伺服器等出口端點之間的裝置。

    • 您必須認識自己的裝置,以便了解發生效能問題的情況 (IP 位址、裝置類型等等)。

    • Proxy 伺服器是常見的出口端點,因此您可以查看網頁瀏覽器設定為使用何種 Proxy 伺服器 (如果有的話)。

    • 您可使用協力廠商工具來探索及對應網路,但是詢問網路小組成員是認識裝置最安全的方法。

  • 識別網際網路服務提供者 (ISP),寫下其連絡人資訊,並詢問您有多少頻寬及迴路。

  • 在您公司內部,識別用戶端和出口端點之間裝置的資源,或識別緊急連絡人以告知網路問題。

以下是簡易測試可使用工具為您計算的幾項比較基準:

  • 從用戶端電腦到出口端點的時間 (以毫秒為單位)

  • 從出口端點到 Office 365 的時間 (以毫秒為單位)

  • 當您瀏覽時,伺服器位於全世界的哪個位置可解析 Office 365 的 URL

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

如果您不熟悉如何執行這些步驟,本文會提供更多詳細資料。

比較基準是什麼?

當情況變差時您會知道其影響,但如果您不知道您的歷史效能資料,就不可能了解何時發生變化以及影響的程度為何。因此若缺少比較基準,您便遺失完成拼圖的重要線索:拼圖盒上的圖片。在效能疑難排解中,您需要比較點。簡單的效能比較基準並不難取得。您的操作小組可排定負責執行這些作業。例如,假設您的連線看起來像這樣:

顯示用戶端、Proxy 及 Office 365 雲端的基本網路圖形。

這表示您已詢問網路小組並發現離開公司後是透過 Proxy 伺服器連至網際網路,而該 Proxy 會處理您的用戶端電腦傳送至雲端的所有要求。在這種情況下,您應該繪製列出所有中繼裝置的簡化版連線。現在請插入工具,以便測試用戶端、出口端點 (您由此點離開您的網路而前往網路網際) 及 Office 365 雲端之間的效能。

含用戶端、Proxy、雲端的基本網路,及工具建議 PSPing、TraceTCP 與網路追蹤。

此處會列出 [簡易] 和 [進階] 兩類選項,這是依據您需具備多少專業知識才能找到效能資料而定。與執行 PsPing 和 TraceTCP 命令列工具相較之下,網路追蹤會花費很多時間。選擇這兩種命令列工具是因為它們不是使用遭 Office 365 封鎖的 ICMP 封包,而且會提供離開用戶端電腦或 Proxy 伺服器 (若您具備存取權) 及抵達 Office 365 的所費時間 (以毫秒為單位)。從一部電腦到另一部電腦的每個個別躍點結尾都有時間值,此即為絕佳的比較基準!同樣重要的是,這些命令列工具可讓您新增連接埠號碼至命令,這點很很實用,因為 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><what's happening in the test> 格式是一個很好的起點。若勤於執行,則將來疑難排解問題時可受益良多。日後您可以說:「我在 2 月 8 日執行兩次追蹤,一次顯示效能良好,一次則顯示效能不佳,讓我們來比較一下吧」。這對於進行疑難排解極為實用。

您必須讓歷程記錄比較基準保持井然有序。此範例中,簡單的方法會產生三個命令列輸出並將結果收集為螢幕擷取畫面面,但您可能有網路擷取的檔案。使用最適合您的方式。儲存歷史比較基準,之後注意到線上服務的行為變更時加以參考。

為什麼在試驗計畫期間收集效能資料?

Office 365 服務的試驗計畫期間是開始進行比較基準的絕佳時間。Office 可能有數千上萬的使用者,也可能是五個使用者,但即使只有少數使用者,您仍可執行測試以測量效能的波動。若在大型公司的代表性範例有數百名使用者測試 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 或兩者組合的大型網路中,您可能需要在允許流量通過大量 URL 的 Proxy 伺服器上設定例外狀況。如需取得 Office 365 使用的端點清單,請參閱 Office 365 URL 與 IP 位址範圍。如果您具備已驗證的 Proxy,請開始測試下列項目的例外狀況:

  • 連接埠 80 和 443

  • TCP 及 HTTPS

  • 輸出至下列任何 URL 的連線:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

所有使用者必須獲得允許可於沒有任何 Proxy 干擾或驗證下取得這些位址。在較小的網路上,您應該將這些位址新增到網頁瀏覽器的 Proxy 略過清單。

若要在 Internet Explorer 中將這些位址新增至您的 Proxy 略過清單,請移至 [工具] > [網際網路選項] > [連線] > [區域網路設定] > [進階]。您也可以在 [進階] 索引標籤中尋找 Proxy 伺服器和 Proxy 伺服器連接埠。您可能需按一下 [在您的區域網路使用 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. 完成下列步驟,以執行提升權限的命令提示字元:

    1. 按一下 [開始]。

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

    3. 如果出現 [使用者帳戶控制] 對話方塊中,請確認其顯示的動作是否符合您的需求,然後按一下 [繼續]。

  2. 瀏覽至安裝工具 (在此例為 PsPing) 的資料夾並測試這些 Office 365 URL:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      指向 microsoft-my.sharepoint.com 連接埠 443 的 PSPing 命令。

請務必包括 443 連接埠號碼。提醒您,Office 365 是在加密通道上運作。如果您使用 PsPing 時缺少連接埠號碼,您的要求將會失敗。一旦您偵測簡短清單,即會尋找以毫秒 (ms) 為單位的平均時間。這就是您要記錄的內容!

圖形顯示從用戶端到 Proxy PSPing 的圖例,來回時間為 2.8 毫秒。

如果您不熟悉 Proxy 略過,但想要逐步執行,必須先尋找 Proxy 伺服器的名稱。在 Internet Explorer 中,移至 [工具] > [網際網路選項] > [連線] > [區域網路設定] > [進階]。您會在 [進階] 索引標籤中看到列出的 Proxy 伺服器。完成這項工作,即可在命令提示字元偵測 Proxy 伺服器:

若要偵測 Proxy 伺服器並以毫秒為單位,取得階段 1 至 2 的來回時間值

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

    1. 按一下 [開始]。

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

    3. 如果出現 [使用者帳戶控制] 對話方塊中,請確認其顯示的動作是否符合您的需求,然後按一下 [繼續]。

  2. 輸入 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 的來回時間為 2.8 毫秒。

如果您的用戶端電腦是具備 Proxy (或出口端點) 伺服器存取權的少數電腦之一,您可遠端連線至該電腦,然後從該處執行命令提示字元以 PsPing 到 Office 365 URL,即可執行測試的下個階段。如果您沒有該電腦的存取權,則可連絡網路資源以了解下個階段的說明,如此便可取得完全相同的數字。如果不可行,請針對上述的 Office 365 URL 執行 PsPing,並將結果與對您的 Proxy 伺服器執行 PsPing 或 Ping 的結果做比較。

例如,若您從用戶端至 Office 365 URL 費時 51.84 毫秒,而從用戶端至 Proxy (或出口端點) 費時 2.8 毫秒,那麼從出口端點至 Office 365 即費時 49.04 毫秒。同樣地,如果您在一天的高峰期間從用戶端 PsPing 至 Proxy 費時 12.25 毫秒,從用戶端至 Office 365 URL 費時 62.01 毫秒,那麼 Proxy 出口端點至 Office 365 URL 的平均值為 49.76 毫秒。

額外的圖形在用戶端到 Office 365 旁顯示從用戶端到 Proxy 的 Ping (以毫秒為單位),以便將這些值相減。

就解決問題來說,維持這些比較基準很可能讓您找到值得探究的情況。舉例來說,若您發現從 Proxy 或出口端點至 Office 365 URL 通常會延遲約 40 至 59 毫秒,從用戶端至 Proxy 或出口端點則延遲約 3 至 7 毫秒 (依您每日於該時段查閱的網路流量而定),當最後三個用戶端至 Proxy 或出口比較基準顯示的延遲為 45 毫秒時,您就能確定某個項目出了問題。

進階方法

如果想查明您傳到 Office 365 的網際網路要求發生了什麼狀況,則必須熟悉網路追蹤。凡是能擷取和篩選網路流量的工具,您都能用於進行這類追蹤:HTTPWatch、Netmon、Message Analyzer、Wireshark、Fiddler,開發人員儀表板工具或任何其他工具皆可。查閱本節的內容後,您會發現執行多種工具更能掌握問題全貌。您在測試時,這其中部分工具本身也可以當做 Proxy。這份姐妹文件 Office 365 效能疑難排解計劃使用的工具包括 Netmon 3.4HTTPWatchWireShark

採取效能比較基準是這種方法的簡單部分,其中許多步驟與疑難排解效能問題時相同。當您採用更進階的方法建立效能比較基準時,必須採取及儲存網路追蹤。本文中的大部分範例都是使用 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 端點

擴展您的技能
探索訓練
優先取得新功能
加入 Office 測試人員

這項資訊有幫助嗎?

感謝您的意見反應!

感謝您的意見反應! 我們將協助您與其中一位 Office 支援專員連絡以深入了解您的意見。

×