工作人員角色WCF性能

我正在嘗試確定性能最佳的WCF服務託管方案。我正在組裝一個非常高容量的內部部署Web應用程序（最終將在Azure中託管）。 ASP.Net應用程序將使用NetTcpBinding與工作角色中託管的WCF服務進行通信。我想驗證以下假設：工作人員角色WCF性能

1）將服務託管在工作角色中，然後使用服務總線（使用ACS進行安全性）來連接客戶端和服務總是比託管工作角色中的WCF服務要慢，直接連接到端點，並使用用戶名/密碼方法。

2）REST服務總是比NetTcpBinding服務慢，因爲它們使用HTTP而不是二進制。

最初，我選擇了ServiceBus方法，因爲我喜歡安全機制的乾淨程度，但除非正在進行的連接可以是直接的，否則中繼將造成相當大的開銷。

基於這些假設，我選擇了：在輔助角色託管 -WCF服務 -custom用戶名/密碼或使用ACS的用戶名/密碼?????? -NetTcpBinding

這聽起來是對的嗎？另一個要求是我需要創建的最少量的安全特定代碼。所以，我應該使用ACS用戶名/密碼模型還是????

有關如何設置性能最佳，最少自定義代碼安全性的任何見解都非常棒！

謝謝

來源

2011-10-20 Mike W

第一：基準，基準，基準。我們對Azure的性能特徵感到非常驚訝;特別是SQL Azure比我們的Rackspace託管系統慢兩到三倍。數據庫和服務器之間的延遲黯然失色。

這就是說：理論上我會證實你的猜測，在客戶端和服務之間使用用戶名/密碼將比ACS更快。

但是您是否需要進行任何憑證檢查？你可以使用私人內部端點（如：http://msdn.microsoft.com/en-us/library/windowsazure/gg432980.aspx） - 如果是這樣，那麼就不需要任何憑證檢查。

如果您確實需要公開一個公共端點，那麼我會認真考慮使用客戶端SSL證書，因爲這可以提供加密以及身份驗證。

關於REST與二進制文件，很大程度上取決於您正在使用的應用程序的類型。我使用Microsoft REST堆棧的經驗是它非常高效：實際上，在連接建立和數據流動的時候，基本上在客戶端和服務器之間有一個原始的TCP連接。但是，使用REST獲得的是HTTP語義，使用負載平衡器的能力以及一般便利。

但是，再次：我會創建一些示例應用程序並測試自己。（並回來後發佈一個鏈接到您的博客條目發佈結果，呃？）

來源

2011-10-20 20:01:02

謝謝傑里米。內部端點的問題在於，只有在Web應用程序託管在Azure中後才能使用，最初不會。你對db和服務器之間的延遲的發現很有趣。我絕對會發表我的發現。感謝帖子！ –

嗯，這很有趣：「Windows Azure在每個公共端點上提供了負載平衡，允許您根據需要將應用擴展到儘可能多的實例。您需要確保您的應用程序是無狀態的（或將狀態存儲在公共區域不同的實例，比如blob或表），唯一沒有負載平衡的端點是內部端點，因此，如果你正在做一些類型的角色間通信，比如從一個web角色到幾個工作角色實例之一，在內部端點上的wcf服務，您需要處理這些實例間的負載平衡。「 SO張貼 –

我不會使用ACL，除非你真的需要它，我不認爲這是你的情況。爲驗證客戶端添加額外的代理將增加不必要的延遲。其次，使用NetTcp不需要輔助角色，只需使用tcp端點配置Web角色即可。這將使用WAS和TCP在IIS中託管您的服務。您甚至可以將Azure上的WCF服務配置爲專用端點，只有在Azure中託管的Web應用程序才能看到，因此不需要進行身份驗證。

來源

2011-10-20 20:08:14

我認爲你的意思是ACS而不是ACL ... –

工作人員角色WCF性能

回答

相關問題