推或查詢

我有一個SL客戶端和一個WCF服務。客戶端每4秒輪詢一次WCF，並且每次有近100個客戶端。推或查詢

網絡服務器是一個512 MB RAM的入門級服務器。

我想知道，如果輪詢依賴於服務器配置，如果我增加服務器配置，客戶端輪詢會更好嗎？

第二，推（雙工）比投票更好嗎？我從我一直在閱讀的博客中得到了一些不同的迴應。

此外，優化輪詢以便客戶更快響應的最佳做法是什麼？我的應用程序需要實時數據

感謝

來源

2011-03-23 Jayesh

你看到什麼問題？ WCF服務在合理的時間內沒有響應嗎？ 4秒（+響應時間）不夠「實時」嗎？ – arootbeer 2011-03-23 15:34:55

問題 - 讓我們談談100個客戶。每隔4秒進行一次民意調查。現在，讓我們隨機poll_no - 客戶應該收到一些數據。我的一些客戶收到它，有些則沒有收到。接下來的民意調查顯示，其他一些客戶會收到，而其他客戶不會收到！ – Jayesh 2011-03-23 15:39:14

WCF服務是做什麼的？它是計算密集型的還是IO綁定的（或以其他方式長期運行？）它是向數據庫發出呼叫還是在進程外做某些事情？聽起來您的服務中存在問題，無論是服務過載還是失敗;投票本身不是問題。如果您針對該服務運行10個客戶端，他們是否每次都得到響應？ – arootbeer 2011-03-23 16:12:09

我的猜測是，你有某種競爭狀態被顯示出來只有與客戶的數量較多。 WCF服務使用什麼併發和實例化模式？（參見MSDN：WCF會話，實例化和併發性在http://msdn.microsoft.com/en-us/library/ms731193.aspx）

如果你正在「失去」的回答，我會做的第一件事就是開始記錄或跟蹤發生的事情在服務器上。例如，當客戶「看不到」響應時，服務器是否收到請求？（如果是這樣，它會發生什麼，等等等）

我也會留意內存使用情況 - 你沒有說你使用的是什麼操作系統，但這些日子512 MB是非常瘦的。如果你進入交換到磁盤的情況，這顯然不會是一件好事。

最後，假設你的服務是CPU綁定的（即沒有沉重的數據庫&文件系統調用），以最好的辦法提高你的吞吐量大概是減少消息負載（導線規格），採用最高效的綁定（也就是說，如果客戶端是.NET並且您控制它，則NetTcp綁定比HTTP快得多），當然還可以多線程處理您的服務。恕我直言，根據您提供的信息 - 以及所有其他條件相同 - 投票可能沒問題，推動可能會讓事情變得更加複雜。如果這很重要，那麼你真的想要爲這個問題帶來一個真正的工程方法，並確定/衡量你的瓶頸。

希望這會有所幫助！

來源

2011-03-24 16:54:36

感謝您的解釋。我正在使用Windows操作系統。我的客戶是SL客戶端，所以我懷疑我是否對綁定有任何靈活性。你認爲增加RAM會帶來更好的性能嗎？ – Jayesh 2011-03-25 06:02:18

「Windows操作系統」將其縮小爲大約十幾個選擇...... ;-) 2000？ 2003？ XP？贏7？您將不得不查看任務管理器或性能計數器以查看正在使用多少內存。有很多資源可以幫助你。 Silverlight是一個MS技術，所以你可以有選擇，當涉及到綁定 - 依賴於客戶端開發團隊是如何解決WCF服務端點（生成的代理 - 難以更改綁定，或配置文件 - 易於更改）。但你真的需要首先解決的下降反應，然後找出你的瓶頸。 – 2011-03-25 18:26:34

其服務器'03。好吧，好的。我會檢查任務管理器。具體而言，我可以監視服務器上的每線程性能嗎？ – Jayesh 2011-03-25 18:27:31

「推送」通知通常具有較低的網絡開銷，因爲沒有任何通信時不會發送流量。但是，「拉」通知通常會降低應用程序開銷，因爲當客戶端只是閒置等待通知時，您不必維護狀態。

推送通知也往往是「更快」，因爲發生事件時會立即通知客戶端，而不是等待下一個輪詢間隔。但是拉取通知更加靈活 - 您可以使用任何您想要的服務器或協議，並且只需將輪詢等待時間加倍就可以使客戶端容量翻倍。

來源

2011-03-24 17:13:58 tylerl

我一直在想這類事情。你知道任何有關各自優點/缺點討論的鏈接嗎？ – 2011-03-24 20:24:55

回答

相關問題