2009-12-02 40 views
3

我必須在我的WCF服務中獲得最大吞吐量性能。在我的一個測試中,使用NetTcpBinding,以下服務每分鐘只能獲得50k個數據項。像NetMsmqBinding這樣的斷開連接可以提高性能嗎?什麼WCF綁定是最高性能的?

服務和客戶端使用WCF並運行在同一臺機器上。

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, 
    ConcurrencyMode = ConcurrencyMode.Multiple)] 
public class Storage : IStorage 
{ 
    protected List<int> _data = new List<int>(); 

    public void Insert(int[] data) 
    { 
     lock (_data) 
     { 
      _data.AddRange(data); 
     } 
    } 

    public int[] Get() 
    { 
     lock (_data) 
     { 
      return _data.ToArray(); 
     } 
    } 
} 

上面的代碼是實際代碼的簡化版本。

+2

有關如何選擇WCF綁定的流程圖,請參閱http://stackoverflow.com/questions/1613586/c-wcf-inter-process-communication/1613601#1613601。它並沒有直接解決績效問題,但其他人看到這個問題可能會有幫助。 – 2009-12-02 21:59:19

回答

4

Msmq可能比TcpBinding慢。

如果您在同一臺計算機上運行,​​您絕對應該使用NetNamedPipeBinding(IPC),它是可用的最快綁定。

您還應該檢查如何序列化數據。與默認的WCF二進制序列化相比,協議緩衝區序列化速度更快(並且更精簡)(但需要稍微調整一下)。

+0

http://code.google.com/p/protobuf-net/wiki/Performance – 2009-12-02 17:56:58

+0

是的。這是兩個具有很好的WCF支持的實現之一。聽說那個lib的創建者並不是一個未知的人,在這裏round。 – 2009-12-02 19:02:25

+0

我用它,但奇怪的是它並沒有改善我的服務的性能 – 2009-12-02 19:55:18

3

如果服務和客戶端運行在同一臺機器上,我會避免網絡完全支持IPC機制,如命名管道。網絡流量引發了很多開銷,可以通過使用IPC機制來避免。

+0

爲命名管道+1。恥辱WCF 4.0不得不放棄localProcessBinding :( – MattC 2009-12-02 17:09:57

2

您是否有理由相信運輸是降低交易速度的原因?分析有什麼告訴你的?此時此服務設置爲單線程,並且還有多個調用「Get」互相鎖定。

這個服務是如何被調用/使用的?它有助於使它成爲多線程嗎?如何使用像ReaderWriterLock這樣更復雜的鎖,它允許多個調用同時發生,但仍然阻止「添加」?

編輯:我知道這是一個簡化的情況,但會從同樣的考慮實際的服務利益?

+0

+1引發問題 – 2009-12-02 17:14:14

+0

我剛剛糾正了併發模式,謝謝! – 2009-12-02 17:16:16

+0

是的,我認爲實際的服務也會受益於先進的鎖定 – 2009-12-02 17:17:51

4

單個呼叫孤立或數千個呼叫洪水更快?

NetMsmq使用MSMQ消息隊列 - 您將消息放入由MSMQ處理的隊列中,服務將最終從該隊列中獲取並處理它。您不會得到即時反饋,這些消息只是單向的。

另一方面NetTcp就像http - 只有更快。您向服務發送請求並立即收到回覆(如果一切順利)。本身沒有消息排隊,你的消息是請求/回覆。

所以我不認爲你可以比較兩個綁定,真的。它們的用途完全不同:

  • 如果您想要查找郵政編碼並獲取該位置的經度/緯度,您絕對需要一個請求/響應機制 - >使用netTcp

  • 如果您想要將請求存入打印文檔或重新組織數據庫或某種性質的內容 - 這些內容最終需要付諸實踐,但您不希望立即回覆回覆(但您可以稍後檢查郵件是否已正確處理),然後用一個消息隊列系統

希望使事情更清楚一點 - 我不認爲這兩個確實相對於相同的一組操作的面向,讓你最有可能永遠不會有之間進行選擇這兩個直接:)

+0

如果你看看我的代碼,如果我告訴你,每個客戶端只使用1個操作(一個客戶端插入,另一個客戶端獲取),我想我們會同意MSMQ適合我的服務。問題是我從來沒有使用它,我不知道它是否是高性能的。 – 2009-12-02 17:23:42

+0

好吧 - 如果你想「獲取」某些東西,你必須向MSMQ發送一個「GET」請求給服務。但是,你如何獲得數據?由於MSMQ總是隻有單向........你幾乎不得不打開服務放置響應的另一個(響應)隊列,客戶端需要從那裏獲取數據。不,我不認爲,一般來說,MSMQ對於GET操作來說是個好主意。 – 2009-12-02 17:28:02

+0

因此,如果我理解你的話,我將不得不忽略這個服務的GET方法,並在接收數據的服務中轉換我的客戶端中的一個,以便使用MSMQ? – 2009-12-02 17:34:06

相關問題