微調及監視效能
我們建議您使用以下可提升同步處理效能的作法：
設定每一部伺服器和資料庫及應用程式程式碼，以達到最佳效能
開發效能基準
監視及微調，以符合或超出基準
組態
效能微調的第一個步驟是確保硬體和軟體都已適當設定。
伺服器和網路考量
請確定每一部電腦都有足夠的 IO 子系統，而且資料庫檔案都已適當配置。
讀取及寫入變更至磁碟的速度通常要比網路速度更重要，所以足夠的 IO 子系統是很基本的條件。建議您使用多個 RAID 磁碟陣列，而且伺服器上的 tempdb、使用者資料庫和交易記錄都必須各有一個專用陣列。tempdb、使用者資料庫和交易記錄應該在個別的檔案群組中建立。如果一個或多個使用者資料表經過證明為處理作業的瓶頸，請考慮將其移到個別的檔案群組。
請考慮增加記憶體到同步處理拓撲中的電腦。
這對於涉及大量並行同步處理工作階段的伺服器而言特別重要。同步處理工作階段通常會牽涉到長期執行的交易，因此擁有極大量的記憶體讓伺服器資料庫可直接定址，將會是一件很重要的事情。如果是 SQL Server，請考慮將 /3GB 參數用於 32 位元系統，或是移到 64 位元系統。如需詳細資訊，請參閱《SQL Server 線上叢書》中的＜處理位址空間＞。
設定配置給伺服器資料庫的最小和最大記憶體數量。
例如依預設，Database Engine 將根據可用的系統資源，動態地變更其記憶體需求。若要在同步處理活動期間避免記憶體可用量過低，請使用 min server memory 選項設定最小可用的記憶體。若要避免作業系統使用磁碟上的分頁檔做為記憶體，亦可使用 max server memory 選項設定最大記憶體數量。如需詳細資訊，請參閱《SQL Server 線上叢書》。
資料庫和應用程式設計
依照資料庫設計的最佳作法。
參與同步處理的資料庫通常也能夠獲益於相似資料庫所採取的效能最佳化。如需最佳化資料庫的詳細資訊，請參閱《SQL Server 線上叢書》。請注意以下的索引考量：
基底資料表上的索引應該使用您打算進行的同步處理活動來加以測試，因為索引可以影響選取、插入、更新和刪除效能。
中繼資料表應該以適當的方式進行索引。Sync Framework 會將索引加入至它所建立的任何資料表。如果您為 DbSyncProvider 建立中繼資料表，請參閱 HOW TO：佈建伺服器資料庫來進行共同作業同步處理 (非 SQL Server)。如果您為 DbServerSyncProvider 建立中繼資料表，請參閱 HOW TO：使用自訂變更追蹤系統。
針對資料庫鎖定逾時和查詢逾時設定適當的值。
透過發行集設計和應用程式行為，將衝突最小化。
應用程式應該做盡量能夠避免衝突的設計，因為偵測與解決衝突會增加額外的複雜性、處理程序以及網路流量。最常見的避免衝突方法如下：
只更新一個節點上的資料表，或
篩選資料，好讓只有一個節點更新一組特定的資料列。例如，在用戶端-伺服器案例中，您可以透過水平方式分割用戶端之間的資料，好讓每一個用戶端都只變更一份資料「配量」，例如位於美國華盛頓州之客戶的連絡人資訊。
明智使用篩選。
篩選資料是減少衝突並將較少資料複製到每個節點的一個很好的方式。但是，請注意複雜的篩選子句會影響效能。如果篩選聯結許多資料表，請考慮其他方法來實作相同的邏輯。
請注意觸發程序和同步處理查詢中的應用程式邏輯。
在每個查詢和觸發程序中執行其他邏輯會大幅降低效能。
請將預存程序用於資料庫命令。
Sync Framework 會使用幾個查詢，以便在同步處理工作階段期間選取及套用資料和中繼資料變更。如果您以手動方式建立這些查詢，請將其封裝在預存程序中。這通常會提供較佳的效能和可維護性，也可以協助保護應用程式的安全。如果您的應用程式需要內嵌 SQL 而不是預存程序，請務必針對所有命令使用 ADO.NET Prepare() 方法。這樣會改善內嵌 SQL 的效能。
只同步處理每一個節點上所需的資料。
您可能會很想要發行資料庫中的全部或大部分資料表 (以防萬一)。請避免發行應用程式並非真正需要的資料表，並考慮以較低的頻率同步處理每個節點。
請適當地設計同步處理群組與範圍，並將適當的同步處理方向用於每一個範圍。
範圍是當做一個單位進行同步處理的一組資料表。可以篩選範圍中的一個或多個資料表，而且資料表可以包含在一個以上的範圍中。請確定範圍會反映其所包含之資料表的結構和使用模式。假設銷售人員應用程式中有下列四個資料表：
Orders 和 OrderDetails
資料列只會插入到用戶端電腦上的這些資料表中，但可能會在伺服器上更新。變更必須在相同的交易中認可。這些資料表應該在相同的範圍中，而同步處理的方向為雙向。
Pricing
資料列會經常插入和更新，但是僅限伺服器上。這個資料表類似於它在一個範圍中所應該具有的面貌，從用戶端的觀點來看，具有僅限下載的同步處理方向。
Products
資料列不會經常在伺服器上插入和更新。這個資料表所在的範圍或許應該與 Pricing 資料表不同，因為它不會依照相同的頻率來更新，而且同步處理的頻率可能也比較低。
注意
每個工作階段的同步處理方向都可以變更，而跨工作階段的範圍仍然存在。範圍與同步處理方向之間並沒有直接的關聯，此範例只是為了說明如何在設計應用程式時同時考慮這兩者。
如果是 DbSyncProvider，請使用 SelectTableMaxTimestampsCommand 來最佳化列舉。
針對這個屬性指定的查詢會從每個基底資料表或追蹤資料表中選取最大時間戳記值。此時間戳記值是用來判斷每個資料表的目的地是否都已經具有來源的所有變更。如果目的地已變更，Sync Framework 通常可以避免執行列舉查詢來提升效能。
請使用批次處理來彌補不可靠的網路和記憶體不足的問題。
根據預設，Sync Framework 會在單一 DataSet 物件中傳遞每一個節點的變更。當變更套用到節點時，這個物件會保留在記憶體中。如果套用變更的電腦上有足夠的記憶體，而且電腦的連接很可靠，預設行為就會運作良好。但是，某些應用程式可能會因為變更分成批次而受益。批次處理確實會導入額外的負荷，它對於某些應用程式而言，實際上會帶來效能優點。如需詳細資訊，請參閱 HOW TO：以批次傳遞變更 (SQL Server)。
交錯同步處理排程。
如果有大量節點與中央節點同步處理，請交錯排程來降低中央節點上的記憶體壓力和爭用情形。排程可以根據時鐘時間或相對時間。例如，應用程式可以每一個小時同步處理一次，或者可以在該節點上一次工作階段成功完成之後的一個小時，啟動同步處理工作階段。
使用適當的中繼資料清除排程。
大量的中繼資料會影響同步處理查詢的效能。
基準
設定同步處理後，建議您開發效能基準，如此可讓您根據應用程式和拓撲的典型工作負載，來判斷同步處理的效能表現。使用同步處理事件和系統監視器來判斷下列五個同步處理效能維度的一般數值：
延遲：資料變更在拓撲的節點之間傳播所花費的時間。
輸送量：系統在一段長時間可承受的同步處理活動量 (以某段時間傳遞的資料列數來測量)。
並行：可以與特定節點同時同步處理的節點數。這通常是可以與特定伺服器同步處理的用戶端數目。
同步處理的持續時間：完成給定同步處理工作階段所需要的時間長度。
資源消耗：用來當做同步處理結果的硬體和網路資源。
根據您的應用程式而定，某些效能量值可能會比其他量值更重要。例如，只要可以維護高等級的並行程度，可以接受擁有相對低的輸送量。在建立基準時，請注意 Sync Framework 並未設計為低延遲的高輸送量伺服器對伺服器的系統，就像 SQL Server 交易式複寫一樣。它是針對支援離線及共同作業應用程式的用戶端對伺服器和用戶端對用戶端的同步處理所設計。
在您建立基準數字後，請監視系統來查看效能和延展性的瓶頸，並視需要進行微調。
監視和維護
監視可以在效能基準的開發期間，定期在實際執行環境中使用，當有效能問題時可以更密集地使用。我們建議您採用下列工具來監視同步處理活動和效能：
同步處理事件
請使用下列事件來判斷特定階段所耗用的時間量：
每個提供者上的每個資料表事件：SelectingChanges、ChangesSelected、ApplyingChanges 和 ChangesApplied
每個提供者上的每個工作階段事件：SyncProgress
請將每一個階段的時間保留在記憶體中，然後在同步處理工作階段結束之後，將結果寫入記錄檔或效能資料庫。
SQL Server Profiler
請使用 TSQL_SPs 範本，並識別所花的時間多於特定臨界值 (如 10 秒鐘) 的任何查詢。如果您將追蹤資訊寫入記錄檔或效能資料庫，請將資料保留在記憶體中，然後在同步處理工作階段結束之後執行寫入。
SQL Server Management Studio
Management Studio 可用來檢查每一個同步處理查詢的查詢計畫，以確定可使用最佳計畫。
系統監視器
請使用下列效能物件和計數器來監視對於同步處理非常重要的地方：
SQL Server 底下的計數器：記憶體管理員。例如，您可以比較 Target Server Memory 和 Total Server Memory，以確認 SQL Server 是否使用提供給它的記憶體。
PhysicalDisk 底下的計數器。例如，Avg. Disk Read Queue Length 和 Avg. Disk Write Queue Length 有助於識別同步處理效能是否繫結 IO 或是電腦的記憶體不足。如果佇列長度不合理，請考慮增加記憶體及升級或新增磁碟機。
預設值是讓計數器報告所有磁碟機中的平均值。請務必針對每個磁碟機新增計數器。
SQL Server 底下的計數器：交易。例如，Snapshot Transactions 和 Version Store Size 可用來判斷變更列舉查詢是否會造成 tempdb 大量成長。變更列舉查詢會使用快照集交易，而快照集的版本資訊會儲存在 tempdb 中。大型的版本存放區表示 tempdb 可能需要重新調整大小。
SQL Server 底下的計數器：鎖定。例如，Lock Wait Time 和 Number of Deadlocks 可用來判斷在資料庫的並行活動期間，爭用情況是不是一個問題。
同步處理追蹤
Sync Framework 包括根據 TraceListener 類別的追蹤。追蹤可用來收集有關同步處理工作階段的資訊，而且對於監視及疑難排解也很有幫助。但是，請注意追蹤會導入額外的負荷，所以主要應該用於開發期間。如需詳細資訊，請參閱 HOW TO：追蹤同步處理程序 (此主題著重於 DbServerSyncProvider，但是資訊也適用於其他提供者)。
除了監視以外，我們也建議您定期執行下列維護工作：
根據磁碟重組程度，在基底資料表和中繼資料表上重新組織或重建索引。
更新索引統計資料。
清除同步處理中繼資料。