了解高項目計數和限制檢視對效能的影響

上次修改主題的時間： 2009-01-14

本主題將幫助您了解、診斷和解決 Microsoft Exchange Server 2007 中，當使用以連線模式執行的 Microsoft Office Outlook、具有委派存取之快取模式的 Outlook，以及 Outlook Web Access 時，與重要路徑資料夾的高項目計數和限制檢視要求有關的效能問題。這些重要路徑資料夾包括 [行事曆]、[連絡人]、[收件匣] 和 [寄件備份] 資料夾。限制檢視是根據搜尋條件來限制資訊的資料檢視，因此只會顯示資料夾的項目子集。與這些情況有關的效能問題，通常與慢速用戶端存取表單中的使用者有關，而且這些使用者能夠看到。只要有少數使用者的重要路徑資料夾中有異常的高項目計數，就會產生能對整個 Exchange 組織造成影響的效能問題。

使用 Exchange Server 2003 時，每個資料夾的建議最大項目計數是 5,000 個項目。而在 Exchange 2007 中，I/O 的改善、較大的分頁大小以及增加的快取都有助於增加建議的最大項目計數。使用架構正確的硬體，可接受的使用者體驗仍然可以維持最大 20,000 個項目的項目計數。

附註：
常見作業的可接受使用者體驗表示從按一下到進行動作的回應時間是 100 毫秒。對於不常使用的作業，例如建立新的排序順序或第一次選取資料夾，可以接受最多 1 分鐘的回應時間。

此建議的最大值根據是否有任何協力廠商程式存取使用者信箱而有所不同。這些協力廠商程式包括下列程式及其他類似的程式：

• Outlook 增益集
• 電子郵件封存
• 防毒
• 行動裝置
• 語音信箱
• 其他可建立額外檢視或搜尋資料夾的程式或 Outlook 增益集

在此情況下，必須檢閱整體伺服器負載，以及伺服器如何處理來自特定協力廠商程式的每個要求，以決定項目計數。

此建議的最大值也取決於 Exchange 環境的效能功能。選擇特定硬體可以降低最大數量。理想上，最好是將 [收件匣] 和 [寄件備份] 資料夾的項目保持低於 20,000 個項目，[連絡人] 和 [行事曆] 項目計數則低於 5,000。即使將項目計數維持為等於或低於建議的最大值，有些作業還是需要較久的時間 (通常大約是 1 分鐘)。這些作業包含新的排序順序以及第一次選取資料夾。資料夾的第一次檢視甚至需要較多的時間才能產生檢視。重要路徑資料夾中的高項目計數會對伺服器效能產生負面影響，因為這些資料夾是使用者信箱中存取最頻繁的資料夾。其他資料夾 (尤其是一般使用者建立的自訂資料夾) 因為不常存取，所以可以處理較大數量的項目而不會對使用者經驗產生負面影響。請注意，雖然不常存取的資料夾擁有高項目計數對效能的影響較少，但是隨著伺服器上這類資料夾和作用中使用者的數量增加，這些資料夾的高項目計數仍會造成短暫的效能問題。

重要事項：
資料夾的第一次檢視甚至需要較多的時間才能產生檢視。因此，移動信箱作業會導致所有具有高項目計數之資料夾的第一次檢視效能降低。已移動至新伺服器的使用者存取其資料夾並重建資料夾檢視時，這可能會導致短暫的效能問題。遵循移動信箱的作業最佳作法 (將移動分散至多部伺服器以及減少同時移動至相同伺服器的信箱數目) 有助於減少此問題的發生。

當您考量組織適用的最大項目計數時，請了解最大值不會突然變得很小，而是漸進式的效能降低。陳述的限制並未進行硬式編碼。而是根據測試和程式碼分析的數字。項目計數增加時，使用者可以察覺到效能降低。您環境中使用者可接受的效能等級會指定環境適用的最大項目計數。

請注意，個別信箱並沒有固有的大小限制。會限制信箱大小的主要因素如下：可用的磁碟空間、備份與還原次數、服務等級協定和 Outlook 效能。說到 Outlook 的效能時，我們特別指的是一般使用者體驗到的延遲。

了解硬體選擇對效能的影響

雖然這個影響顯而易見，但仍說明如下：如果您組織的硬體大小不適當，在項目數量較少的時候就可能會發生效能低落的情況。在連線模式中，系統的 I/O 需求會隨著信箱中項目計數的增加而成長。因此評估硬體在高項目計數的效能時，磁碟延遲是最重要的硬體考量因素之一。若要有最佳的使用者體驗，請確保伺服器即使在尖峰用量期間，磁碟延遲仍然很低 (20 毫秒或更少)。

若要顯示磁碟延遲的增加及對伺服器效能的影響，請考慮下列範例。在要求檢視時，會個別執行資料的要求，序列化磁碟的要求，不會大量作業。例如，如果外掛程式傳回一個 1000 個項目的檢視，則 Exchange 儲存區可能會進行約 200 次的個別資料要求 (假設每個要求會擷取約 5 個訊息)。在 20 毫秒時，單是磁碟子系統就會有 4 秒的延遲。請考慮當磁碟延遲增加到 50 毫秒或 100 毫秒時效能影響的增加。如果有多個正在使用的外掛程式都進行類似的要求，這個問題就會更加惡化。在這種情況下，使用者可能會感覺 Outlook 時常很擁塞。

如需更多關於伺服器尺寸的建議，以確保使用 Exchange 2007 時有良好效能，請參閱規劃您的伺服器和儲存架構。

了解為什麼會需要額外的處理時間

在考慮高項目計數和限制檢視要求對伺服器處理能力之效能的影響時，您應該要留意會發生的基本程序，以及高項目計數和限制檢視要求與那些程序的關係。

資料夾內容是以表格形式儲存在資訊儲存區資料庫中。隨著項目數量的增加，儲存的複雜性也會相對的增加。Exchange 儲存區的儲存機制是可延伸儲存引擎 (ESE)。ESE 會使用 B+ Tree 資料結構來儲存記錄。隨著記錄數量的增加，尋找資訊和周遊 B+ Tree 所需之磁碟 I/O 要求的數量也會增加。如需相關資訊，請參閱可延伸儲存引擎架構。

隨著項目數量的增加，任何所需資料放在硬碟上實際相鄰位置的可能性就會大幅降低。因此就會需要更多的 I/O 要求。

建立限制檢視需要從 Exchange 伺服器處理。

有兩種方法可篩選 MAPI 中的郵件：

• 搜尋資料夾

• 限制
  在 MAPI 表格上呼叫 IMAPITable::Restrict 方法可建立限制。結果產生的表格只會顯示符合指定限制的項目。限制的內容表格只會顯示來自單一資料夾的郵件。這種限制有時候可能會與 MAPI 定義的結構 (描述搜尋資料夾的篩選條件) 混淆。這種 MAPI 定義的結構亦稱為限制。

搜尋資料夾和限制需要額外的處理。例如，建立搜尋資料夾並在搜尋資料夾中填入符合使用者條件的項目。這項程序需要檢查資料夾中的每個項目，來判斷是否每個項目都應該要放進搜尋資料夾中。因此，當資料夾包含許多項目時，就需要更多的時間才能建立檢視。這些搜尋資料夾會儲存成 SearchFID，並放在產生搜尋的每個資料夾下。依預設，搜尋資料在填入項目後，最多可以存在 40 天。

限制檢視的存在會影響資料夾中項目修改的速度。當某個資料夾有相關聯的搜尋資料夾時，在其他資料夾中增加、刪除或更新項目時就需要進行更多的處理。這是因為 Exchange 必須判斷搜尋資料夾是否需要更新所造成的。當您建立許多搜尋資料夾時，每次變更都必須評估所有搜尋資料夾，才能判斷搜尋資料夾是否需要進行更新。

當有更多非標準內容新增到 Outlook 的資料夾檢視時，可能會需要額外的遠端程序呼叫 (RPC)，才能從 Exchange 儲存區擷取非標準內容。當資料夾內有許多項目時，就會需要更多的來回時間才能從 Exchange 伺服器擷取資料。

在您嘗試檢視某個行事曆資料夾時，Outlook 必須尋找特定日期範圍內的所有約會。這個動作至少需要兩個處理要求。第一個要求會取得指定之日期範圍內的所有靜態約會。第二個要求則會尋找所指定日期範圍內發生的任何週期性約會。而處理第二個要求所需的時間，和行事曆資料夾中項目的數量成正比。這是因為 Outlook 會要求所有週期性約會所造成的。在收到週期性約會的清單後，Outlook 接著會檢查每個週期性約會，以判斷約會是否發生在指定的日期範圍內。如果行事曆中有許多項目，就會需要更多的時間來處理這些要求。

了解項目計數與信箱大小對效能的影響

請注意，大部分的效能問題都不是信箱尺寸太大 (指 2GB 或以上的信箱) 所造成，相反的，大部分都是伺服器的資料夾中正在存取的項目數量所造成。資料夾中有太多項目會嚴重影響效能，因為資料夾需要花費更長的作業時間。尤其是下列重要路徑資料夾中的項目數量，對效能有很大的影響：[行事曆]、[連絡人]、[收件匣] 和 [寄件備份] 資料夾。如需如何規劃大量信箱的相關資訊，請參閱White Paper:Planning for Large Mailboxes with Exchange 2007。

而與資料夾中項目數量有關的作業包括：將新欄位新增到檢視、在新欄位進行排序、尋找和搜尋。許多 Outlook 外掛程式在執行時會同時進行排序或搜尋，這些要求會與其他 Outlook MAPI 要求重疊。因此會造成不良的使用者經驗。

如果您目前正在執行快取模式 (Outlook 2003 及更新版本的預設模式)，則隨著資料夾中項目數量逐漸增加，用戶端效能就會產生問題。其中一件您可以做的事，就是避免讓 OST 檔案 (本機資料快取) 太過分散。您可以使用 Windows SysInternals 工具 Contig 來達成這個目的。若要下載最新版本的 Contig，請參閱 Contig v1.55。

除了重要路徑資料夾中項目的數量外，還有其他幾個因素會因為高項目計數而讓 Outlook 經驗更加惡化，例如其他 MAPI 應用程式的數量，或是使用者電腦上執行的 Outlook 外掛程式。所有的 MAPI 要求都需要時間來處理 emsmdb32.dll。因此，如果使用者有許多外掛程式進行要求，Outlook 的執行速度就會變慢，對伺服器的影響就會增加。此外，所要求動作的複雜度也會對效能產生影響。例如，將某個資料夾中的所有項目都標示為 [已讀取] 所花費的時間，就會比只標示一個項目久。而其他可能需要花費更多時間的動作包括：擷取眾多使用者對某個會議邀請的空閒/忙碌資訊，或是對多個資料夾進行搜尋。如果使用者經常執行複雜的動作、擁有許多 Outlook 外掛程式，或是經常使用 [連絡人] 和 [行事曆] 資料夾，則他們因為高項目計數而遭遇效能低落的可能性就會大幅增加。

了解限制檢視 (MAPI 限制)

MAPI 通常會以表格形式呈現資料。當用戶端要求提供者清單時就會出現一個表格顯示資料夾、資料夾內容、附件等等。每個表格都會由多個欄位組成。而每個欄位都有不同的 MAPI 內容來表示各個屬性，像是寄件者、主旨和傳遞時間。表格的每一列都代表一個特定項目。以資料夾內容表格為例，每一列都代表一封郵件。而這些表格上的用戶端動作都是依活動呈現，就像是在排序資料。用戶端可以搜尋表格中符合特定條件的特定列。這項作業稱為 FindRow()。用戶端還可以要求只將符合特定條件的項目納入表格中。例如，只納入特定日期建立的項目。這就是所謂的限制。因而產生的資料夾內容表格就只會有符合該指定條件的項目。如果預期用戶端會經常要求呈現相同的資料，就可以使用限制。

限制檢視如何影響效能

若要了解限制對效能造成的影響，您必須考慮實際上儲存 MAPI 用戶端所要求資料的資訊儲存庫，以及資訊儲存庫如何解譯像是 FindRow 和 Restrict 這類要求。在儲存區的儲存架構內，會使用各種表格來共同表示信箱、資料夾、資料夾內容和郵件等項目。

當用戶端要求某個資料夾的內容清單時，這個要求會對應到稱為「郵件資料夾表格」(MsgFolder) 的特定資料夾。系統內建立的每個資料夾都有個別的郵件資料夾表格。MsgFolder 表格的作用是要將資料夾對應到其內容。

為了要處理預期的 Restrict 呼叫 (經常重覆要求相同的資料)，系統會建立一個特別的新資料夾 (以及對應的 MsgFolder 表格)，稱為「限制搜尋資料夾」。這個資料夾會連結回原始的資料夾，而這兩個資料夾間會存在邏輯關係。因為搜尋資料夾上有一個條件，所以資料夾中只會包含符合限制所指定之條件的項目。在這個搜尋資料夾中，MsgFolder 表格中符合限制條件的每個郵件，都會有一個連到 MsgFolder 表格中原始列的反向連結。

因為這個行為需要時間來管理每個搜尋資料夾的更新，所以會造成效能問題。當原始資料夾發生變更時，這項變更就會去比較每個與所查詢資料夾相關的限制搜尋資料夾，以判斷這些資料夾是否也需要更新。當一或多個資料夾有許多搜尋資料夾時，這就會造成很大的影響。第二個會遇到的問題是建立限制搜尋資料夾。在建立限制搜尋資料夾時需要對原始資料夾進行完整的檢查，才能擷取必須連結到限制搜尋資料夾的個別項目。如果這個程序是因為用戶端的動作而產生，時間的延遲可能會造成使用者當機，或是出現 Outlook RPC 快顯方塊，指出要求處理的時間太長。建立限制搜尋資料夾所需的時間，和一般資料夾中項目的數量成正比。隨著資料夾中項目數量的增加，這些項目放在相鄰磁碟磁區的機率就會大幅降低。這會導致在對具有高項目計數的資料夾進行限制檢視要求時，隨機磁碟 I/O 會顯著增加。隨著對具有高項目計數之資料夾的限制檢視要求數量的增加，存取該伺服器資源的所有使用者都會感受到 I/O 增加的影響。

在 Exchange 2000 Server、Exchange Server 2003 和 Exchange Server 2007 中，每個資料夾允許的限制搜尋資料夾數量都有上限。預設的上限數量為 11，而預設的搜尋資料夾存留時間為 40 天。

限制搜尋資料夾是以先進先出 (FIFO) 的原則處理。如果資料夾已經有相關的 11 個限制搜尋資料夾，而且進行一個新的限制要求，就會使用上次實際使用的限制來評估搜尋資料夾清單。這表示最少使用的限制搜尋資料夾會被移除，以允許處理新要求。如前所述，這需要完整檢查一般 MsgFolder 表格，如果這個動作是由用戶端直接進行，在建立表格並顯示給用戶端時，用戶端可能會感覺到效能問題。這很可能是因為每天或每週要求超過 12 個限制搜尋資料夾所造成。這樣會讓用戶端產生目前沒有相符搜尋資料夾的限制要求。進而刪除和建立新的限制搜尋資料夾。所有這些要求都會依序進行處理。這也就表示，如果您有許多使用者，當他們會定期要求限制檢視的資料夾中有非常高的項目計數時，那些要求就會排入佇列。而所有正在存取位於該伺服器之信箱資料的使用者，就會感覺到速度變慢。請注意，這不只會影響正在存取其信箱的使用者。其他伺服器上的使用者在存取儲存於該伺服器上的行事曆資料時，也會同樣感受到速度變慢。

重要事項：
對 Outlook Web Access 使用者和處於連線模式的 Outlook 使用者而言，在用戶端安裝其他地區設定可以建立更多的檢視。

限制檢視和共用行事曆

在檢視某人的 [行事曆]、[連絡人] 資料夾等等時，可能會在短暫延遲後才能檢視該資料夾。在檢視過該資料夾時，切換後再次返回時就會相當迅速。但在過了一段時間後，存取該資料夾的速度又會變慢。如果行事曆中有超過 5000 個項目，延遲就會特別久。

當 Outlook 存取某人的資料夾時，會套用某個檢視，限制使用者檢視私人項目。

這個套用檢視到資料夾的動作會在儲存區中建立搜尋資料夾。當搜尋資料夾建立時，就會被快取以供稍後使用。如果使用者嘗試建立一個已經存在的搜尋資料夾，就會使用已經快取的搜尋資料夾。這會讓後續的檢視變得相當快。

依預設，Exchange 不會無限期地快取所有搜尋資料夾。快取太多搜尋資料夾會造成與更新搜尋資料夾有關的伺服器端延遲。相反的，如果快取的搜尋資料夾數量不足，則會因為必須產生和更新搜尋資料夾而發生類似的問題。

為了要描述這個問題，請考慮這個案例：Exchange 伺服器已經設定每個資料夾保留 11 個搜尋資料夾 (檢視)。假設 Frank 和其他 15 位使用者共用某個行事曆資料夾。Sally 在存取該資料夾且建立自己的搜尋資料夾時發生延遲。但在資料夾建立後，存取就變快。然後 Sally 那天都沒有再檢視該資料夾，而其他 11 位使用者則繼續存取該資料夾。Exchange 就會為他們各建立一個新搜尋資料夾。因為只能快取 11 個搜尋資料夾，所以當第 12 位使用者點擊該資料夾時，Exchange 就會刪除為 Sally 建立的搜尋資料夾。現在，當下次 Sally 點擊該資料夾時，她就需要等待 Exchange 為她建立搜尋資料夾。

假設我們將 Frank 的 Mailbox Server 改設為快取 20 個檢視。則 Sally 和其他 14 位使用者都可以點擊 Frank 的行事曆資料夾，而且只會建立 15 個搜尋資料夾。因為 15 比 20 少，所以不需要依序移除檢視，因此每個人在初次點擊以建立搜尋資料夾後，存取速度都會變快。

預設的快取搜尋資料夾數量是 11。此組態是設定於資料庫層級。使用 ADSIEdit 可以檢視所設定的值。請使用 ADSIEdit 來檢視儲存區物件，然後檢查 msExchMaxCachedViews 屬性。辨別名稱如下：

CN=Database, CN=Storage Group,CN=InformationStore,CN=Server NAME,CN=Servers,CN=AG Name,CN=Administrative Groups,CN=Orgname,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com.

在某些情況下，修改該值以增加到 11 以上，對調整效能對環境的影響非常有用。

重要事項：
[msExchMaxCachedViews] 屬性值不可以設為高於 50。

重要事項：
如果您的環境中有 Outlook 2003 RTM，請務必部署 Service Pack 1 或更新版本，以解決使用共用行事曆時效能低落的已知問題。

若要確保您目前閱讀的是最新資訊，並尋找其他的 Exchange Server 2007 說明文件，請造訪 Exchange Server 技術資源中心.