On/Off Assessments 的結果

本主題可協助您解讀 On/Off Assessments (Boot Performance (Fast Startup)、Boot Performance (Full Boot)、Standby Performance 與 Hibernate Performance) 產生的結果。它也會指導您使用產生的結果識別並解決多個在電腦關機和開機時,會讓使用者產生負面經驗的常見問題。

在本主題中:

如需 On/Off Transition 評定的詳細資訊,請參閱 On/Off Transition Performance

您可以建立自訂目標,在 Results View 中測量您的改進功能。目標檔案是分級工具,協助您了解電腦的執行以及比較您企業中的電腦。

例如,基本膝上型電腦的目標也許跟高階桌上型電腦所設定的目標不同,或是隨著時間演變及科技進步,市場期望可能也會隨著改變,您需要有定義不同目標與主要需求的彈性。

當衡量標準值與該衡量標準的目標比較時,會在 Result View 中以顏色標示狀態,如下所示:

  • 淺紫色表示系統能提供出色的使用者經驗,而且沒有偵測到問題。

  • 中紫紅色表示提供的使用者經驗尚可,而您可以對系統進行最佳化。檢閱建議和分析,了解可以對系統進行哪些改善。這些可能是軟體變更、設定變更或是硬體變更。

  • 暗紫色表示系統的使用者經驗不佳,而且還有很明顯的改善空間。檢閱建議和分析,了解可以對系統進行哪些改善。這些可能是軟體變更、設定變更或是硬體變更。您可能必須做一些取捨以提供高品質的 Windows 使用經驗。

  • 沒有顏色表示未針對衡量標準定義任何目標。

note備註
在 Windows 8 的 Windows 評定工具組中,有些評定包含預設目標檔案。您第一次使用此版本的工具檢視結果時,會使用預設目標檔案。不過,您也可以定義 Windows 8 的自訂目標,與定義 Windows 8.1 的自訂目標方式相同。

您可以先設定目標檔案位置,並將目標檔案新增到該位置,才能使用 UI 套用自訂的目標。一旦選取目標檔案,就會在開啟的任何結果中一直使用此目標檔案。

一次只能使用一個目標檔案。所有評定的目標都會設定在單一目標檔案中。評定工具會依照下列順序搜尋目標:

  1. 自訂目標檔案

  2. 結果檔案中定義的目標

  3. 評定資訊清單中定義的目標

您可以使用 %PROGRAMFILES%\Windows Kits\8.1\Assessment and Deployment Kit\Windows Assessment Toolkit\SDK\Samples\Goals 提供的範例目標檔案來建立自己的目標檔案。

note備註
您不可以將目標檔案與工作封裝在一起,但可以將它儲存到共用中供其他人使用。

本節描述 On/Off Assessments 所回報的主要衡量標準、這些衡量標準結果不佳的常見原因以及與這些衡量標準相關的常見問題補救措施。本節也會協助您識別衡量標準最適合的目標對象。

本節內容:

note備註
如果您啟用 [Enable Minifilter Diagnostic Mode] 設定,則評定結果將包含迷你篩選器衡量標準。如需迷你篩選器衡量標準與結果的詳細資訊,請參閱Minifilter Diagnostics

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Boot Performance (Full Boot)

  • Standby Performance

  • Hibernate Performance

此衡量標準會測量電腦花費在關機或暫停操作的時間。下表描述每個評定的衡量標準:

 

評定 衡量標準描述

Boot Performance (Fast Startup) Assessment

此衡量標準會擷取開始執行關機階段到完成將 hiberfile 寫入到磁碟並轉換為低電源狀態 (S4) 的時間。

Boot Performance (Full Boot) Assessment

此衡量標準會擷取開始執行關機階段到轉換為電源關閉狀態的時間。

Standby Performance Assessment

此衡量標準會擷取開始執行暫停階段到轉換為低電源狀態 (S3) 的時間。

Hibernate Performance Assessment

此衡量標準會擷取開始執行休眠到完成將 hiberfile 寫入到磁碟並轉換為低電源狀態 (S4) 的時間。

Detailed Sub-metrics

衡量標準展開後,會顯示關機或暫停子階段。

note備註
子階段期間的加總不一定等於整體期間。

Typical Influencing Factors

此衡量標準是系統關機/暫停的整體衡量標準。它會受到關機/暫停路徑上執行的任一軟體元件的影響。

Analysis and Remediation Steps

展開此衡量標準可查看子衡量標準,這些子衡量標準提供關機/暫停各個子階段的詳細資訊。檢查個別子階段衡量標準和問題,識別潛在延遲因素。

Relevant Assessments:

  • Boot Performance (Fast Startup)

此衡量標準會測量電腦花費在關閉使用者工作階段的時間。此階段包含關閉使用者工作階段處理程序、登出使用者,並將 Winlogon 通知傳達給訂閱者。衡量標準展開後,會顯示關機或暫停子階段。

note備註
子階段期間的加總不一定等於整體期間。

此衡量標準是系統關機的整體衡量標準。它會受到關機路徑上執行的任一軟體元件的影響。

Analysis and Remediation Steps

展開此衡量標準可查看子衡量標準,這些子衡量標準提供關機各個子階段的詳細資訊。檢查個別子階段衡量標準和問題,識別潛在延遲因素。

Most Applicable to:應用程式開發人員

Relevant Assessments:

  • Boot Performance (Fast Startup)

當評定起始使用者工作階段關機時,會傳送 WM_QUERYENDSESSION 訊息給每個圖形化使用者介面 (GUI) 應用程式中的各個 UI 執行緒。當 Windows 收到 WM_QUERYENDSESSION 訊息的回應後,會將 WM_ENDSESSION 傳送到相同的執行緒。如果 5 秒鐘後有任一應用程式未回應這些通知,Windows 會終止應用程式。只要任一應用程式沒有立即回應該訊息,就會造成系統關機延遲。

note備註
若使用者起始關機作業,逾時時間經過之後,會顯示使用者對話方塊。此對話方塊會顯示導致無法關機之應用程式的相關資訊,而且可以讓使用者ForceCancel關機。

此衡量標準會測量電腦花費在關閉使用者工作階段中所有處理程序的時間。

Detailed Sub-metrics

衡量標準展開後,會顯示一組更詳細的子衡量標準檢視,這些子衡量標準會測量每個個別處理程序花費在回應關機通知的時間。各欄會顯示下列資訊:

  • [Detail] 欄會顯示依反覆運算排序的 PID。在預設檢視中,此欄可能會包含「不同的」值,因為無法彙總不同反覆運算的 PID。展開反覆運算以查看個別的 PID。

  • 此特定處理程序在此階段中所使用的時間。

Typical Influencing Factors

此衡量標準會擷取有待回應關機通知之 UI 執行緒的所有執行中處理程序的累計時間。除了所有處理程序回應的累計時間之外,此衡量標準還會受到花費太多時間之單一處理程序的影響。

具有 UI 執行緒的每個處理程序在回應 WM_QUERYENDSESSION message 或 WM_ENDSESSION 訊息時若有所延遲,會造成系統關機延遲。

note備註
處理程序必須是執行中才會影響此衡量標準。 此評定會在收集用於分析的資料之前先重新開機,因此執行中的處理程序幾乎全部來自啟動應用程式或排程工作。

Analysis and Remediation Steps

您可以使用尋找佔最大比例的處理程序技術來識別對此衡量標準影響最大的處理程序。

如有可能,請從啟動路徑移除應用程式。評定會在執行測量之前先重新開機,因此關機時執行的應用程式就是開機時所啟動的應用程式。最好的做法就是維持最少的啟動應用程式。如果某個非必要的應用程式是造成延遲的原因,請考慮從啟動應用程式清單中移除該應用程式。

尋找造成延遲回應 WM_QUERYENDSESSION 訊息或 WM_ENDSESSION 的可能原因,然後疑難排解並修正相關的問題。如需常見的最佳做法清單,請參閱時效性工作的最佳做法

其他資訊

Most Applicable to:Winlogon 訂閱者開發人員、群組原則指令碼擁有者、系統管理員

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Boot Performance (Full Boot)

  • Standby Performance

  • Hibernate Performance

此衡量標準會測量 Winlogon 所花費的時間,包括花費在執行訂閱者通知/回呼的時間。

對於 Boot Performance (Fast Startup) 案例,Windows Assessment Console 中的 [Winlogon Notifications] 衡量標準會反映花費在處理所有 Winlogon 訂閱者通知與回呼的累計時間。但是,為了在 Windows® Performance Analyzer (WPA) 時間表中提供上下文資訊,[Winlogon Notifications] 活動會從第一個訂閱者通知/回呼開始,並在最後一個結束。花費在處理每個通知的時間是以個別子活動表示。

Boot Performance (Fast Startup) 是提供此衡量標準之額外子衡量標準的唯一評定。在暫停期間,Winlogon 會發出如下四種通知類型的同步訂閱者通知給已註冊的訂閱者:

  • 終止工作階段

  • 結束殼層

  • 登出

  • 建立工作階段

衡量標準展開後,會顯示這四個通知類型的子衡量標準。每種類型都有做為額外子衡量標準的訂閱者清單 (例如,設定檔與 GPClient),而且每個訂閱者都會列出該訂閱者的特定 Connect to SubscriberCall Subscriber 執行個體。

在任一案例中,Winlogon 訂閱者如果花費很長的時間來處理這些通知,就會造成關機/暫停延遲。例如,設定檔服務 (設定檔) 必須同步使用者設定檔 (若電腦上的Roaming (Remote) Profiles功能已啟用)。另一個例子是系統或網域原則可能會設定群組原則用戶端 (GPClient),讓它在使用者登出時執行某些工作。這些工作一般應該是由系統或網域系統管理員設定的。

Typical Influencing Factors

檢查此衡量標準時,應著重在 Winlogon 訂閱者。

Analysis and Remediation Steps

檢查個別訂閱者操作的時間。一般而言,如果訂閱者期間較長,就會產生特定問題。開啟 WPA 並移至訂閱者的時間間隔以了解更多的資料。例如,如果 GPClient 訂閱者呼叫花費了 10 秒鐘,在 WPA 檢查這段期間會發現在這 10 秒鐘內,有 9 秒的時間在執行特定自訂指令碼。這指出該指令碼很可能是延遲的根本原因。

其他資訊

MSDN:Winlogon 通知事件

Most Applicable to:應用程式開發人員

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Standby Performance

  • Hibernate Performance

此衡量標準會測量電腦花費在通知處理程序電源狀態變更的時間。

在此階段中,用戶端/伺服器執行階段伺服器子系統 (Csrss.exe) 會使用事件類型 PBT_APMSUSPEND 向每個擁有視窗的應用程式廣播 WM_POWERBROADCAST 視窗訊息。系統可能也會關閉監視器的電源。

在 WPA 的 [Activities] 圖中,此活動會顯示為正要停止之連續處理程序間的大間隙。關閉監視器電源預計需要多花費一秒以上的時間。這是暫停/關機期間的必要階段,因此不應該被視為此衡量標準的效能瓶頸。

在此期間查看 [CPU Usage (Sampled)] 圖以在下列堆疊上顯示 csrss.exe 處理程序中的 CPU 使用率:

[Root] (csrss.exe) 
winsrv.dll!RegisterForDeviceBroadcastNotifications 
|- winsrv.dll!ZwUserCallNoParam 
|    win32k.sys!xxxUserPowerStateCalloutWorker 
|    |- win32k.sys!PowerOffMonitor 
|    |    |- win32k.sys!FadeDesktop 
|    |    |- win32k.sys!DrvSetMonitorPowerState 
|    |    |- win32k.sys!UpdateDisplayState 
|    |    |- win32k.sys!DwmSyncClearSwapChain 
|    |    |- win32k.sys!RestoreGammaRamp

其他堆疊上 Suspend Processes中因為 CPU 消耗而產生的間隙,或目前堆疊上不含 CPU 使用率的延遲,即表示有必要進一步調查的區域。

衡量標準展開後,會顯示更詳細的階段檢視,其中包含一組子衡量標準,這些子衡量標準會測量每個處理程序花費在回應暫停通知的時間。各欄會顯示下列資訊:

  • [Detail] 欄會顯示依反覆運算排序的 PID。在預設檢視中,此欄可能會包含「不同的」值,因為無法彙總不同反覆運算的 PID。展開反覆運算以查看個別的 PID。

  • 此特定處理程序在此階段中所使用的時間。

note備註
如果應用程式有一個以上的視窗,相同的處理程序可接收一個以上的通知。

Typical Influencing Factors

每個應用程式如果延遲回應事件類型為 PBT_APMSUSPEND 的 WM_POWERBROADCAST 訊息,就會造成系統關機延遲。因為此衡量標準會擷取所有 Windows GUI 處理程序花費在回應暫停通知的累計時間,所以如果單一處理程序使用的時間太長,除了會影響所有處理程序回應的累計時間之外,也會影響此衡量標準。請注意,只有執行中的處理程序才會影響此衡量標準;因為 Boot Performance (Fast Startup) 評定會在收集資料進行分析前先重新開機,所以這些處理程序幾乎全部來自啟動應用程式或排程工作。

Analysis and Remediation Steps

識別對此衡量標準影響最大的處理程序。在 Windows Assessment Console 中,展開 [Suspend Processes Duration] 衡量標準以取得此階段的詳細資料。在此階段的 [Process] 清單中,以遞減方式排序 [Duration],然後尋找佔最大比例的處理程序。

如有可能,請從啟動路徑移除應用程式。最好的做法就是維持最少的啟動應用程式。如果某個非必要的應用程式是造成延遲的原因,請考慮從啟動應用程式清單中移除該應用程式。

疑難排解並修正對啟動路徑有重大影響之處理程序的問題時,必須深入分析應用程式延遲現象。如需常見的最佳做法清單,請參閱時效性工作的最佳做法

其他資訊

MSDN:PBT_APMSUSPEND 事件

Most Applicable to:Windows 服務開發人員

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Standby Performance

  • Hibernate Performance

此衡量標準會測量電腦花費在通知服務電源狀態變更的時間。已登錄要接收電源管理事件 (SERVICE_ACCEPT_POWEREVENT) 的所有服務都會收到暫停通知。因為這些通知會連續傳送,服務中的任何延遲都會直接對整體關機/暫停期間造成影響。系統會強制使用 30 秒的逾時 (以各個服務為基礎) 來處理此通知;在此逾時後,系統會進入下一個階段。登錄此通知為選擇性動作,因此作業系統不需要服務執行特定動作。

Detailed Sub-metrics

衡量標準展開後,會顯示更詳細的階段檢視,其中包含個別服務清單與其對應的期間。

Typical Influencing Factors

此衡量標準會擷取所有服務花費在回應電源查詢的累計時間。除了所有處理程序回應的累計時間之外,此衡量標準還會受到花費太多時間之單一處理程序的影響。

大部分的服務不需要進行任何重要工作來回應待命與休眠電源通知。從服務的觀點來看,快速啟動與休眠類似。

Analysis and Remediation Steps

識別對此衡量標準造成重大影響的服務。如果服務回應中較長的延遲,通常在指定服務中就會產生特定問題。產生這類問題時,您可以依照問題內的連結檢視進階問題詳細資料。如果未產生問題,就需要在 WPA 中進行後續分析。此額外的分析不在本文的討論範圍內。如需最佳做法的詳細資訊,請參閱時效性工作的最佳做法

其他資訊

MSDN:OnNow/ACPI 支援

Most Applicable to:應用程式開發人員、Windows 服務開發人員

Relevant Assessments

  1. Boot Performance (Fast Startup)

  2. Standby Performance

  3. Hibernate Performance

此衡量標準會測量 Windows Superfetch 服務花費在針對後續開機/繼續準備記憶體狀態的時間。Superfetch 會預先擷取啟動期間頻繁存取的資料,並將其儲存在 hiberfile (用於 Boot Performance (Fast Startup) 與 Hibernate Performance) 或主記憶體 (Standby Performance),以避免繼續時大量存取磁碟。此功能可加快繼續程序的速度。

Typical Influencing Factors

在此階段中,Superfetch 服務會存取啟動期間讀取的資料。此階段的期間會直接受到啟動應用程式、服務、認證提供者等在啟動期間必須讀取之資料量的影響。

Analysis and Remediation Steps

此階段需要使用本文未提及的進階分析。

Most Applicable to:驅動程式開發人員

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Standby Performance

  • Hibernate Performance

在關機/暫停階段期間,系統會傳送具有 IRP_MN_QUERY_POWER 次要代碼與電源狀態 (S4 代表 Boot Performance (Fast Startup)/Hibernate Performance,S3 代表 Standby Performance) 的電源 IRP 給每個裝置驅動程式。此衡量標準會測量處理查詢電源 IRP 之所有驅動程式的期間。

每個驅動程式如果沒有立即處理 IRP,就會造成系統關機延遲。

Detailed Sub-metrics

衡量標準展開後,會顯示更詳細的階段檢視,其中包含裝置清單與其對應的期間。

Typical Influencing Factors

此衡量標準會擷取所有驅動程式花費在回應電源查詢的累計時間。除了所有驅動程式回應的累計時間之外,此衡量標準還會受到花費太多時間回應之單一驅動程式的影響。

Analysis and Remediation Steps

您可以透過查看子衡量標準,識別對於此衡量標準有重大影響的驅動程式。如果驅動程式回應期間有較長的延遲,通常在指定驅動程式中就會產生相關問題。產生這類問題時,請依照問題內的連結檢視進階問題詳細資料。如果未產生問題,就需要在 WPA 中進行後續分析 (不過這不在本文的討論範圍內)。如需常見的最佳做法清單,請參閱時效性工作的最佳做法

note備註
如果驅動程式擁有裝置的電源原則,它會產生裝置電源 IRP 以回應接收系統電源 IRP。驅動程式不應該先等候裝置 IRP 完成才完成系統 IRP,因為這樣會讓其他裝置無法接收其系統 IRP。這一連串的等候會導致序列化延遲,並增加整體暫停時間。

其他資訊

MSDN:IRP_MN_QUERY_POWER

Most Applicable to:應用程式開發人員、Windows 服務開發人員

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Standby Performance

  • Hibernate Performance

此衡量標準會測量電腦花費在寫入登錄並將任何其他已修改分頁儲存至次要存放裝置的時間。

Typical Influencing Factors

此衡量標準所代表的時間取決於需要排清的資料量。

Analysis and Remediation Steps

若要識別此資料是由哪些處理程序負責,將需要執行進階分析 (不過這不在本文的討論範圍內);但是,可能的目標為在關機前寫入大量資料的處理程序。

範例:結束前寫入一個數 MB 之資料檔案 (直接透過快取的 I/O) 的應用程式,或是在關機時修改大量檔案對應記憶體的服務。

Most Applicable to:驅動程式開發人員

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Standby Performance

  • Hibernate Performance

在 Boot Performance (Fast Startup) 案例的關機階段,系統會傳送電源 (IRP_MJ_POWER) I/O (具有 IRP_MN_SET_POWER 次要代碼與電源狀態 (S4 代表 Boot Performance (Fast Startup) 或 Hibernate Performance,S3 代表 Standby Performance) 的 IRP) 給每個裝置驅動程式。

此衡量標準會測量所有驅動程式處理設定電源 IRP 所需的時間。

當裝置驅動程式處理此 IRP 時,它們會儲存適當的裝置上下文 (如有必要),並將裝置切換到適當的狀態以因應將睡眠或休眠的系統。每個驅動程式如果沒有立即處理 IRP,就會造成系統關機延遲。

Detailed Sub-metrics

衡量標準展開後,會顯示更詳細的階段檢視,其中包含裝置清單與其對應的期間。

Typical Influencing Factors

此衡量標準會擷取所有驅動程式花費在回應電源查詢的累計時間。除了所有回應的累計時間之外,此衡量標準還會受到花費太多時間回應之單一驅動程式的影響。

note備註
如果驅動程式擁有裝置的電源原則,它會產生裝置電源 IRP 以回應接收系統電源 IRP。驅動程式不應該先等候裝置 IRP 完成才完成系統 IRP,因為這樣會讓其他裝置無法接收其系統 IRP。這一連串的等候會導致序列化延遲,並增加整體暫停時間。

Analysis and Remediation Steps

您可以透過查看子衡量標準,識別對於此衡量標準有重大影響的驅動程式。如果驅動程式回應期間有較長的延遲,通常在指定驅動程式中就會產生相關問題。產生這類問題時,請依照問題內的連結檢視進階問題詳細資料。如果未產生問題,就需要在 WPA 中進行後續分析;此類型的分析不在本文的討論範圍內。

其他資訊

MSDN:IRP_MN_SET_POWER

Most Applicable to:應用程式開發人員、Windows 服務開發人員、驅動程式開發人員

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Hibernate Performance

此衡量標準會測量系統花費在將主記憶體的相關內容寫入到次要存放裝置的時間;具體而言是寫入到 hiberfile.sys 檔案,它通常位於系統磁碟機的根目錄。

Detailed Sub-metrics

衡量標準展開後,會顯示以 KB 表示的 hiberfile 大小。

Typical Influencing Factors

寫入 hiberfile 所花費的時間與必須寫入的資料量成正比。除了系統必須在系統繼續 (如 Superfetch 準備記憶體階段所指出) 期間讀取的任何資料,此資料還包括作業系統、驅動程式與服務所使用的記憶體。

必須使用大量記憶體的驅動程式若指示記憶體管理員將資料寫入 hiberfile 中,就會影響此衡量標準。或者,啟動應用程式也可能在繼續路徑中造成必須讀取大量資料。在這些案例中,Superfetch 服務可確保資料已包含在 hiberfile 中,避免繼續路徑發生回應緩慢的隨機錯誤。

note備註
硬碟實體效能特性 (例如,循序寫入輸送量) 也會影響此衡量標準。

Analysis and Remediation Steps

若要識別哪個元件佔最長的 hiberfile 寫入期間,您必須進行詳細的記憶體分析,但這不在本文的討論範圍內。不過,每個執行中的驅動程式與服務如果有過多的記憶體配置作業,都會影響此衡量標準。啟動應用程式的數目與所使用的資源,以及在啟動期間讀取資料的其他元件,也會影響此衡量標準。

Most Applicable to:BIOS 製造商

Relevant Assessments:

  1. Boot Performance (Fast Startup)

  2. Boot Performance (Full Boot)

  3. Standby Performance

  4. Hibernate Performance

此衡量標準會測量平台韌體花費在識別並初始化硬體裝置及執行開機自我測試 (POST) 的時間。

note備註
BIOS 初始化會在作業系統收到控制權之前進行。此評定無法徹底調查該階段,而且只能回報它的期間。

Detailed Sub-metrics

Boot Performance (Fast Startup) 是提供此衡量標準之額外子衡量標準的唯一案例。對於包含支援最新進階組態與電源介面 (ACPI) 標準 (ACPI 5.0) 的 BIOS,您可以展開此衡量標準以顯示韌體效能資料表 (FPDT) 回報的 POST 時間。這是 BIOS 初始化期間 (由核心設備所回報) 的替代測量方式。

Typical Influencing Factors

為系統設定的開機順序是 BIOS 初始化延遲的重大來源。此順序會要求系統在載入 Windows 之前檢查可開機的光碟機、軟碟機、USB 或其他硬碟。PXE 開機 (網路/遠端開機) 也可能被設定為開機順序的一部分;若啟用此選項,它也會對延遲造成重大影響。某些 BIOS 設定也具有需要花比較長的時間完成的進階診斷或驗證模式。

Analysis and Remediation Steps

不會針對 BIOS 階段擷取額外資訊。您應該檢查典型的影響因素 (例如,PXE 開機是否已啟用)。需要檢查這些設定的問題或變更這些設定時,您應該洽詢 BIOS 製造商。本文將不繼續討論更深入的 BIOS 初始化階段調查。

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Boot Performance (Full Boot)

  • Standby Performance

  • Hibernate Performance

此衡量標準會測量電腦花費在啟動的時間。此衡量標準會擷取從 BIOS 初始化結束後,一直到後續開啟/關閉階段結束 (當系統進入閒置狀態時結束) 的時間。

Detailed Sub-metrics

衡量標準展開後,會顯示開機/繼續子階段清單。

note備註
子階段期間的加總不一定等於整體期間。

Typical Influencing Factors

此衡量標準是系統開機/繼續的整體衡量標準,任何在開機路徑執行的軟體元件都會影響此衡量標準。

Analysis and Remediation Steps

展開此衡量標準可查看子衡量標準,這些子衡量標準提供個別子階段的詳細資訊。檢查個別子階段衡量標準和問題,識別潛在延遲因素。

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Boot Performance (Full Boot)

  • Standby Performance

  • Hibernate Performance

此衡量標準會測量電腦開始啟動到顯示使用者桌面的時間。此衡量標準會擷取從 BIOS 初始化結束到顯示 Windows 8 UI 的時間,而且不包括後續開啟/關閉階段。

Detailed Sub-metrics

衡量標準展開後,會顯示子階段 (後續開啟/關閉階段除外) 清單。

note備註
子階段期間的加總不一定等於整體期間。

Typical Influencing Factors

此衡量標準是開機/繼續到顯示桌面的整體衡量標準。任何在顯示桌面前執行的軟體元件都會影響此衡量標準。

Analysis and Remediation Steps

展開此衡量標準可查看子衡量標準,這些子衡量標準提供個別子階段的詳細資訊。檢查個別子階段衡量標準和問題,識別潛在延遲因素。

Most Applicable to:系統管理員

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Boot Performance (Full Boot)

  • Hibernate Performance

此衡量標準會測量在 Windows 開機磁碟分割尋找並啟動 Winload.exe (作業系統載入器) 的時間。

Typical Influencing Factors

此衡量標準會受到 BitLocker 作業的影響,特別是 BitLocker 需要 PIN 才能啟動時。

Analysis and Remediation Steps

使用不需要手動輸入 PIN 的 BitLocker 解除鎖定方法。

Most Applicable to:應用程式開發人員、Windows 服務開發人員、驅動程式開發人員

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Hibernate Performance

此衡量標準會測量系統花費在將 hiberfile 內容讀到主記憶的時間。

Detailed Sub-metrics

衡量標準展開後,會顯示 hiberfile 大小 (以 KB 表示)。

Typical Influencing Factors

花費在讀取 hiberfile 的時間與必須讀取的資料量成正比。除了系統用於系統繼續 (在關機/暫停的 Superfetch 準備記憶體階段) 的資料之外,此資料還包括記憶體中供作業系統、驅動程式與服務使用的資料。

note備註
硬碟實體效能特性 (例如,循序讀取輸送量) 也會影響此衡量標準。

Analysis and Remediation Steps

若要識別哪個元件佔最長的 hiberfile 讀取期間,您必須進行詳細的記憶體分析,但這不在本文的討論範圍內。

note備註
每個執行中的驅動程式與服務如果有過多的記憶體配置作業,都會影響此衡量標準。啟動應用程式的數目與所使用的資源,以及在啟動期間讀取資料的其他元件,也會影響此衡量標準。

Most Applicable to:驅動程式開發人員

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Standby Performance

  • Hibernate Performance

在關機/暫停期間,系統會傳送具有 IRP_MN_SET_POWER 次要代碼與工作中電源狀態的電源 (IRP_MJ_POWER) IRP 給每個裝置驅動程式。裝置驅動程式接著會傳送裝置電源 IRP 給對應的裝置。此衡量標準會測量所有驅動程式處理設定電源 IRP 的時間。

note備註
在此階段中,驅動程式不應該保留系統電源 IRP。每個驅動程式如果沒有立即處理系統電源 IRP,就會造成系統啟動延遲。

Detailed Sub-metrics

衡量標準展開後,會顯示更詳細的階段檢視,其中包含裝置清單與其對應的期間。

Typical Influencing Factors

此衡量標準會擷取所有驅動程式花費在回應 IRP_MN_SET_POWER 電源要求的累計時間。除了所有驅動程式回應的累計時間之外,此衡量標準還會受到花費太多時間回應之單一驅動程式的影響。

note備註
如果驅動程式擁有裝置的電源原則,它會產生裝置電源 IRP 以回應接收系統電源 IRP。驅動程式不應該先等候裝置 IRP 完成才完成系統 IRP,因為這樣會讓其他裝置無法接收其系統 IRP。這一連串的等候會導致序列化延遲,並增加整體暫停時間。

Analysis and Remediation Steps

您可以透過查看子衡量標準,識別對於此衡量標準有重大影響的驅動程式。如果驅動程式回應有較長的延遲,通常在指定的驅動程式中就會產生相關問題。產生這類問題時,請依照問題內的連結檢視進階問題詳細資料。如果未產生問題,就需要在 WPA 中進行後續分析 (不過這不在本文的討論範圍內)。請參閱時效性工作的最佳做法

其他資訊

MSDN:IRP_MN_SET_POWER

Most Applicable to:系統管理員

Relevant Assessments:

  1. Boot Performance (Fast Startup)

此衡量標準會測量作業系統選取功能表花費在選取預設項目的時間。根據預設,會在 30 秒後選取 (如果沒有使用者互動)。

Typical Influencing Factors

此衡量標準不受系統行為的影響。只有已安裝多個作業系統的系統才會回報此衡量標準,而且如果沒有使用者互動,一律會回報 30 秒。

note備註
雖然系統行為不會影響此衡量標準的期間,但是開機程序具有許多會在此期間執行的非同步處理程序。這些處理程序會影響選取預設選項之後發生之活動的結果,因為在這些期間執行的工作中,有某些工作可能已完成。

Analysis and Remediation Steps

移除要分析的作業系統以外的所有作業系統。若要檢視目前已安裝的作業系統清單 (包括會影響此功能表的設定),請在命令提示字元中執行 msconfig.exe,然後選擇 [開機] 索引標籤。

Most Applicable to:Winlogon 訂閱者開發人員、群組原則指令碼擁有者、系統管理員、認證提供者開發人員

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Hibernate Performance

此衡量標準代表多個 Winlogon 外呼和操作 (例如,與 Winlogon 訂閱者的互動) 的總時間長度。此衡量標準不是花費在訂閱者通知的累計時間,因此不應該如此看待。

Detailed Sub-metrics

Boot Performance (Fast Startup) 是提供此衡量標準之額外子衡量標準的唯一評定。衡量標準展開後,會顯示更詳細的階段檢視,其中包含每個 Winlogon 訂閱者所花費的時間。在繼續期間,Winlogon 會發出下列兩種通知類型的同步訂閱者通知給已註冊的訂閱者:

  • 登入

  • 啟動殼層

衡量標準展開後,會顯示這兩種通知類型的子衡量標準。每種類型都有做為額外的子衡量標準的訂閱者清單 (例如,設定檔或 GPClient)。每個訂閱者都會列出該訂閱者的特定 Connect to SubscriberCall Subscriber 執行個體。

對於所有案例,Winlogon 訂閱者如果花費很長的時間來處理這些通知,就會造成關機延遲。例如,設定檔服務 (設定檔) 必須同步使用者設定檔 (若電腦上的Roaming (Remote) Profiles功能已啟用)。或者,系統或網域原則可能已設定群組原則用戶端 (GPClient),讓它在使用者登入時執行特定工作。這些工作一般是由系統或網域系統管理員所設定,而且通常是執行非 Microsoft 擁有的指令碼。

Typical Influencing Factors

檢查此衡量標準時,應著重在處理登入和啟動殼層通知的 Winlogon 訂閱者。

Analysis and Remediation Steps

檢查個別訂閱者操作的時間。較長的訂閱者期間通常會產生特定問題。您也可以開啟 WPA 並切換到某個訂閱者的時間間隔,以檢視詳細資料。例如,如果 GPClient 訂閱者呼叫花費了 10 秒鐘,在 WPA 檢查這段期間會發現在這 10 秒鐘內,有 9 秒的時間在執行特定自訂指令碼。這可以在 [Process Lifetimes] 圖中看到。它表示此指令碼可能是延遲的根本原因。

其他資訊

Winlogon 通知事件

Most Applicable to:啟動應用程式開發人員

Relevant Assessments:

  • Boot Performance (Fast Startup)

此衡量標準會擷取從 Winlogon 階段結束,直到 Windows 殼層 (Explorer.exe) 回報已初始化 [開始] 畫面為止的時間。此衡量標準包括啟動 userinit.exe 處理程序 (它會接著啟動 Explorer.exe)。此衡量標準也包括儲存在 RunOnce 登錄機碼之啟動應用程式的初始化。

Typical Influencing Factors

如果沒有 RunOnce 應用程式,則此階段大部分的時間應該都花費在初始化檔案總管處理程序。在此初始化程序中,檔案總管會讀取一些程式庫和資料檔,並將它們放入記憶體中。和其他執行中的元件爭用 I/O 會干擾此活動並造成此活動延遲。

Analysis and Remediation Steps

較長的檔案總管初始化階段通常會產生特定問題。您可以開啟 WPA 並切換到檔案總管初始化活動的時間隔間隔以檢視詳細資料。避免將應用程式放入定期執行的 RunOnce 機碼中,因為這樣會延長檔案總管初始化時間。

調查檔案總管初始化期間的特定問題不在本文的討論範圍內。如需常見的最佳做法清單,請參閱時效性工作的最佳做法

Most Applicable to:應用程式開發人員

Relevant Assessments:

  • Boot Performance (Fast Startup)

  • Boot Performance (Full Boot)

  • Standby Performance

  • Hibernate Performance

此衡量標準會測量從 Post On/Off 完成,直到系統正常閒置而且可以回應使用者輸入的時間。此階段的目標是限制並量化在 [開始] 畫面顯示後仍繼續執行的背景處理作業。此衡量標準會測量後續開啟/關閉階段的期間,它代表系統累計 5 秒閒置時間所需的時間。此時間的累計方式是檢查 CPU 與存放裝置使用情況 (檢查間隔為 500 毫秒)。如果 CPU 與存放裝置兩者的累計時間低於 20%,此期間的閒置時間 (500 毫秒 - 此期間的最大值 [CPU 時間,磁碟時間]) 會累計至總閒置時間,直到達到 5 秒。此衡量標準會回報此期間減去 5 秒的收集閒置時間。

note備註
進行這些計算時會忽略低優先順序 CPU 與存放裝置使用時間。

任何在此階段中執行的軟體元件,只要執行磁碟 I/O 或進行計算就會影響此階段期間。

Detailed Sub-metrics

此階段沒有實際的子衡量標準;不過,由於階段期間和資源使用量成正比,因此您可以檢查在此階段中執行的處理程序以取得更多的資訊 (展開 Windows Assessment Console 中的 [Processes per Phase])。

Typical Influencing Factors

任何在此階段中使用 CPU 或存放裝置資源的軟體元件都是影響整體時間的潛在因素。額外的啟動應用程式通常會對後續開啟/關閉階段造成負面影響。

在 Standby Performance 和 Hibernate Performance 案例中 (不會登出使用者工作階段),此階段會受到在目前工作負載中執行之應用程式的影響。

Analysis and Remediation Steps

識別消耗最多資源的處理程序。若要這樣做,請展開 Windows Assessment Console 中的 [Processes per Phase],或查看 WPA 中的 CPU 與磁碟使用率圖表和摘要表格。發生問題的處理程序也可能會產生問題。如需詳細資訊,請參閱<查看資源使用率衡量標準>。

若要解決 Boot Performance (Fast Startup) 與 Boot Performance (Full Boot) 評定的問題,請考慮移除啟動路徑中不必要的應用程式,或使用 [工作排程器] 將這些應用程式排定在稍後啟動。如果應用程式在使用者登入程序中是非常重要的一環 (例如,該應用程式提供認證提供者服務或網路服務),請確定已將該應用程式最佳化,讓它可以使用最少的資源。

避免使用 Managed 程式碼 (以 CLR 為基礎) 啟動應用程式,因為這些應用程式的初始化作業牽涉到使用大量資源的 .NET Framework 初始化。這樣會進一步影響後續開啟/關閉階段時間,並造成使用者回應延遲。

On/Off Transition Performance 評定會執行進階問題分析,並提供 WPA 連結以疑難排解評定所發現的問題。當 WPA 開啟時,您可以取得磁碟活動或 CPU 活動的其他詳細資料 (取決於問題的類型)。本節說明可用來分析效能問題的調查技術。

Find the Largest Contributor

在 Windows Assessment Console 中開啟評定結果檔案,並展開對應的父衡量標準。子衡量標準通常會提供影響父衡量標準之特定元件的相關資訊。

例如,以Shutdown Processes Duration衡量標準為例。您可以展開該衡量標準以檢視此階段的三個子衡量標準表格。前兩個表格顯示 CPU 與磁碟使用率,第三個表格顯示要關閉之個別處理程序的期間。

其他欄 (例如 [Detail] 欄) 提供子衡量標準的詳細資料。在 [User Session Shutdown Processes] 中,[Detail] 欄會顯示 PID。

note備註
在預設檢視中,[Detail] 欄可能會包含「不同的」值,因為無法彙總不同反覆運算的 PID。展開反覆運算以查看個別的 PID。

Windows Assessment Console 可讓您將子衡量標準清單依任一資料欄排序 (最上層的 [快速啟動] 階段清單除外,它依關機/開機期間的階段順序排序)。

例如,在展開的User Session Shutdown Duration階段中,在表格標頭上按一下滑鼠右鍵,然後選擇 [Sort rows descending]。

您可以為多個最上層階段期間使用此技術。

Look at Resource Utilization Metrics

檢視此階段中每個處理程序的詳細資源使用率。若要抓取此資訊,請展開適當區段中每個階段索引標籤的處理程序,然後依 CPU 使用率或總磁碟使用率排序。

Additional Information

如需深入分析問題和建議的詳細資訊,請參閱常見的深入分析問題

當電腦上已登錄維護工作,但維護工作並未在評定執行之前完成,會發生此錯誤。這會造成評定無法執行,因為維護工作通常會影響評定衡量標準。

若要解決這個問題,請執行下列其中一項:

  1. 確定電腦連接至網路,且使用 AC 電源執行。從已提升權限的命令提示字元執行以下命令,手動初始擱置的維護工作:

    rundll32.exe advapi32.dll,ProcessIdleTasks

  2. 停用一般和閒置的維護工作,並在執行評定之前停止所有維護工作。

如果您不希望工作被延遲,請確定工作沒有任何需要長時間才能完成的作業。請避免下列事項。

  • 如果回應的時效性很重要 (例如,在關機期間處理 WM_ENDSESSION),請勿計劃在接收要求時執行任何重要工作 (除了必須完成的資料可靠性工作 (例如儲存使用者修改的資料) 以外)。

  • 除非絕對需要,否則請避免執行需要長時間才能完成的操作。將這些工作延後至目前時效性工作完成後再進行。避免使用包含「使用此 API 時,請考量效能問題」警告的任何 API。

  • 避免使用需要網路連線的功能,因為網路問題會延遲所有網路要求。在啟動和關機情況下更是需要注意這一點,因為您無法保證網路永不中斷。

  • 避免過長的逾時。如果必須等候,請確定等候時間是在合理的短 (在需要考慮時效性工作的情況下) 逾時值限制內。

  • 避免大量的計算。請記住,處理器的速度各有不同,因此在非常快速的電腦上花費 100 毫秒可以完成的計算,在較慢的電腦上可能需要數秒鐘的時間才能完成。

  • 避免不必要的存放裝置 I/O。I/O 要求可能被其他元件延遲。如果一般系統正在執行大量應用程式和服務,則存放裝置資源就會受限。您的 I/O 要求可能會排在其他元件之數百個類似要求的後面。

  • 避免磁碟排清 (例如,呼叫 FlushFileBuffers API 而起始的磁碟排清)。排清會讓磁碟堆疊刪除其快取,而且會強制硬碟將資料寫入 RAM 緩衝區。通常這種操作十分耗費資源,而且因為硬碟通常會忽略要求,所以無法保證資料的一致性。

  • 避免呼叫 RegFlushKey API 排清登錄區。因為登錄的設計因素,所以該 API 會讓整個登錄區中的修改資料被排清到磁碟,這是十分耗費資源的操作。排清登錄機碼一般而言是不需要執行的動作,因為作業系統會針對所有元件提供一致的登錄檢視。此外,登錄本身每隔幾秒鐘就會進行非同步排清。

  • 因為 RPC 驗證程序相當耗費資源,所以請避免開啟新的 RPC 連線。建立新的 RPC 連線會執行耗費資源的安全性檢查。

  • 避免呼叫交易式 API (例如 TxF API),因為它們一般會針對每個 API 呼叫執行多個耗費資源的操作。這些 API 會捨棄效能來換取可靠性,所以在時效性工作期間不應該使用這些 API。

另請參閱

顯示:
© 2014 Microsoft