控制資源使用並改善效能
此主題描述 Windows Communication Foundation (WCF) 架構的不同領域中，用於控制資源消耗並影響效能度量資訊的各種屬性。
WCF 中限制資源消耗的屬性
Windows Communication Foundation (WCF) 因安全或效能的考量，對特定型別的程序加以限制。 這些限制主要有兩種形式，可能是配額與節流閥。 「配額」(Quota) 是一種限制，當達到或超過這個限制時，會觸發系統中某一點的立即例外狀況。 「節流閥」(Throttles) 則是不會立即造成擲出例外狀況的限制。 相反地，當達到節流閥限制時，仍將持續處理，但會在節流閥的值所設定的限制範圍內。 此限制處理可能在其他地方觸發例外狀況，不過需視應用程式而定。
除了配額與節流閥之間的差異外，有些限制屬性位於序列化層級，有些位於傳輸層級，有些則在應用程式層級。 例如，全由系統提供的傳輸繫結項目實作之 System.ServiceModel.Channels.TransportBindingElement.MaxReceivedMessageSize 配額，預設為 65,536 位元組，防止惡意用戶端利用消耗過多記憶體的方式，對服務發動阻絕服務攻擊 (一般而言，您可調低此值以增進效能)。
序列化配額的範例為 System.Runtime.Serialization.DataContractSerializer.MaxItemsInObjectGraph 屬性，這種屬性會指定序列化程式在單一 ReadObject 方法呼叫中，序列化或還原序列化的物件最大數量。 應用程式層級的節流閥範例為 System.ServiceModel.Dispatcher.ServiceThrottle.MaxConcurrentSessions 屬性，其預設的同時工作階段通道連線數為 10 (與配額不同，若達到此節流閥值，應用程式會持續處理，但不接受新工作階段通道，也就是說在其他工作階段通道結束之前，新用戶端將無法連接)。
這些控制項在設計上是要提供緩和特定類型攻擊的現成方法，或是改善效能度量資訊，例如記憶體使用量、啟動時間等等。 然而，根據應用程式而定，這些控制項會阻礙服務應用程式的效能，甚至造成應用程式無法運作。 例如，設計處理視訊資料流的應用程式，可能很容易就超過預設的 System.ServiceModel.Channels.TransportBindingElement.MaxReceivedMessageSize 屬性。 此主題提供適用於 WCF 所有層級應用程式之各種控制項的概觀，描述各種取得設定是否妨礙應用程式之詳細資訊的方法，以及描述修正各種問題的方法。 多數節流閥與某些配額可在應用程式層級取得，即使基底屬性為序列化或傳輸限制。 例如，您可設定 System.Runtime.Serialization.DataContractSerializer.MaxItemsInObjectGraph 屬性使用服務類別上的 System.ServiceModel.ServiceBehaviorAttribute.MaxItemsInObjectGraph 屬性。
.gif "Bb463275.note(zh-tw,VS.100).gif") 注意： |
|---|
| 如果您有特定問題，請先閱讀 WCF 疑難排解快速入門，查看問題 (及解決方法) 是否列於此處。 |
限制序列化程序的屬性列於資料的安全性考量。 限制使用傳輸相關資源的屬性列於傳輸配額。 限制消耗應用程式層資源的屬性為 ServiceThrottle 類別之成員。
偵測應用程式及與配額設定值相關的效能問題
上述值的預設值選取原則是讓各種應用程式類別都能有基本應用程式功能，同時提供對一般安全性問題的基本保護。 然而，不同應用程式的設計可能會超出一個或更多個節流閥的設定值 (雖然在其他方面，應用程式依然安全，且一如往常般運作)。 出現這些狀況時，您必須找出是哪些節流閥值被超過以及超過多少，然後決定應對方法以增加應用程式的輸送量。
一般而言，撰寫應用程式與偵錯時，您會在組態檔或以程式設計的方式，將 System.ServiceModel.Description.ServiceDebugBehavior.IncludeExceptionDetailInFaults 屬性設為 true。 如此會指示 WCF 傳回服務例外狀況堆疊，追蹤至用戶端應用程式加以檢視。 此功能會報告多數的應用程式層級例外狀況，顯示可能造成問題的配額值 (若該值為問題所在)。
有些例外狀況會在執行階段在低於應用程式層可見範圍之下發生，並且無法使用此機制傳回，這些例外可能無法透過自訂的 System.ServiceModel.Dispatcher.IErrorHandler 實作來處理。 如果您處於像是 Microsoft Visual Studio 的開發環境之下，這些例外狀況大多會自動顯示。 然而，有些例外狀況可以透過開發環境設定值加以遮罩，例如 Visual Studio 2005 的 Just My Code (英文) 設定值。
不論您開發環境的功能如何，您都可以使用 WCF 追蹤與訊息記錄功能偵錯所有例外狀況，並調整應用程式的效能。 如需詳細資訊，請參閱使用追蹤來疑難排解應用程式。
效能問題與 XmlSerializer
使用資料型別 (可使用 XmlSerializer 加以序列化) 的服務和用戶端應用程式會在執行階段針對這些資料型別產生和編譯序列化程式碼，這可能會導致啟動的效能變慢。
| 注意： |
|---|
| 預先產生的序列化程式碼只能用於用戶端應用程式中，而不能用於服務中。 |
ServiceModel 中繼資料公用程式工具 (Svcutil.exe) 可以透過從這些應用程式的已編譯組件產生必要序列化程式碼的方式，改善應用程式的啟動效能。 如需詳細資訊，請參閱 HOW TO：使用 XmlSerializer 改善 WCF 用戶端應用程式的啟動時間。
在 ASP.NET 下裝載 WCF 服務時的效能問題
在 IIS 和 ASP.NET 下裝載 WCF 服務時，IIS 和 ASP.NET 的組態設定可能會影響 WCF 服務的處理量和記憶體使用量。 如需詳細資訊 ASP.NET 效能的詳細資訊，請參閱提升 ASP.NET 效能 (英文)。 一個可能會造成意外結果的設定是 ProcessModelSection 的屬性 MinWorkerThreads。 如果您的應用程式有固定或少量的用戶端，將 MinWorkerThreads 設定為 2 可能會讓 CPU 使用率接近 100% 的多處理器電腦提高處理量。 但提高效能有其代價：這也會造成記憶體使用量增加，因而減少延展性。