WCF 3.5 vs 4.0 RESTful Services性能

我有一些使用WCF 3.5 + RESTful入門工具包開發的WCF RESTful服務。我遇到了許多同樣的抱怨，它不是非常高效，並且不能很好地處理一連串的請求。我認爲這個原因的一部分是3.5中的RESTful特性更像是一個社區插件。WCF 3.5 vs 4.0 RESTful Services性能

既然WCF 4.0 RESTful服務已經出現一段時間了，我推測有些人已經開發出來並在生產環境中使用它。

我在使用WCF REST服務模板40（CS），看到任何人有任何性能/可伸縮性問題。我還在檢查WCF 3.5和WCF 4.0的RESTful服務之間是否進行了性能/可伸縮性比較。做一個快速的谷歌搜索沒有產生很多結果。

任何反饋將不勝感激。

編輯

每請求，這是我的配置：

<bindings> 
    <webHttpBinding> 
    <binding name="TransportWeb"> 
     <security mode="Transport"> 
     <transport clientCredentialType="None"/> 
     </security> 
    </binding> 
    </webHttpBinding> 
</bindings> 

<services> 
    <service behaviorConfiguration="SecureBehavior" name="Service"> 
    <endpoint address="" binding="webHttpBinding" bindingConfiguration="TransportWeb" behaviorConfiguration="REST" contract="IServce"/> 
    <endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange"/> 
    </service> 
</services> 

<behaviors> 
    <serviceBehaviors> 
    <behavior name="SecureBehavior"> 
     <serviceMetadata httpGetEnabled="false" httpsGetEnabled="true"/> 
     <serviceDebug includeExceptionDetailInFaults="true"/> 
    </behavior> 
    </serviceBehaviors> 
    <endpointBehaviors> 
    <behavior name="REST"> 
     <webHttp/> 
    </behavior> 
    </endpointBehaviors> 
</behaviors>

來源

2011-05-27 Brandon

其中一些「社區」功能是WCF 4中的那些新功能。 – 2011-05-27 21:01:53

之前我們怪你建立在框架技術，告訴我們更多關於您的具體實現。我個人發現WCF本身的各個方面都可以在適當槓桿化的情況下進行擴展。通常情況下，你會發現這是一個人應該責怪的具體實現/配置。

因此，這裏是你實現一些問題，希望能幫助社區幫助您更好地：

你派出什麼樣的要求？
您使用的入門工具包有哪些功能？
你的綁定配置如何？
你正在流入或流出任何二進制數據？
您使用任何安全措施嗎？（SSL，用戶/密碼等）
您是否在執行任何長時間運行的任務？

更新1

所以，一切看起來不錯，從綁定的角度和你解釋什麼，它聽起來就像你有一個漂亮的「香草」 WCF服務在這裏。這聽起來並不像你在描述中使用the WCF 3.5 REST Starter Kit framework中的任何一個，所以我不確定你是否遺漏了一些細節，或者你是否錯誤地說你使用它。

有一件事我注意到你沒有在你的服務配置中做任何明確的<serviceThrottling>值。默認情況下，在.NET 3.5中，最大併發呼叫數僅爲。因此，根據您的通話時間和您客戶在任何給定時間的飽和度，您可能會被拒之門外。如果你check out this MSDN section titled Optimizing WCF Web Service Performance你會看到一些指導，建議實際配置maxConcurrentCalls爲每個核心16。這是.NET 4的一個不同之處，因爲如果您沒有指定自己的顯式值，它們會自動爲您自動執行16 *個內核。自然地，爲您的應用程序找到最佳位置的唯一方法是通過負載測試和數字播放。

說了這麼多，我從你提供的信息中看到的錯誤並不多。如果您告訴我們更多有關您的Web服務內部的信息，或許我們可以就如何實現更好的性能提出更好的建議。對於我們現在所知的所有問題，您的瓶頸可能在您與之交互的某個數據庫中。

因此，要回答這個問題的標題：在這一點上，我不認爲有任何東西阻止你，因爲你使用3.5。在4.0中肯定會有一些性能改進，但是在這裏或者其他任何方面你都沒有談論超大規模，就像我說的那樣，根據你的描述，你並不是真的在做任何複雜的WCF定製或者任何其他的東西。

來源

2011-05-27 21:26:09

我添加了我的綁定。我正在使用一個漂亮的HTTPS POST調用。我沒有進行任何流式傳輸。對於任何請求，我沒有任何長時間運行的任務。主要是獲取單個記錄或保存單個記錄。我沒有使用任何自定義註釋。只是我的類的基本WebInvoke，OperationContract，ServiceContract和DataContract屬性。我擁有的大部分是非常基本的。就請求數量而言，我們每分鐘對API進行大約100-200次請求。 – Brandon 2011-05-27 21:44:13

根據您的更新更新了我的答案。 – 2011-05-28 03:16:43

我能夠通過做3件事來大幅提高性能。 1.切換到WCF 4.0，我能夠利用Global.asax中的Application_start事件。 2.使用服務調節。 3.使用Mikael答案中的代碼示例來實現CLR .NET Worker線程池。 – Brandon 2011-06-01 03:19:08

請參閱http://blogs.msdn.com/b/endpoint/archive/2011/05/04/wcf-scales-up-slowly-with-bursts-of-work.aspx瞭解有關此原因和解決方案的更多信息。

根據您的意見，您確實有數據庫調用。考慮到線程池的工作方式，您應該始終針對需要高吞吐量的同步IO綁定操作進行調整。

來源

2011-05-28 04:52:03

您的答案除了德魯的提供非常有用的讓我大大提高性能。 – Brandon 2011-06-01 03:19:36

WCF 3.5 vs 4.0 RESTful Services性能

回答

相關問題