.NET WebService IPC-是否應該這樣做以最大程度地減少一些昂貴的操作？

Question

我正在尋找解決問題的幾種不同方法：客戶端請求工作，完成一些工作，並返回結果（確定/錯誤）。

.NET Web服務絕對看起來像是要走的路，我唯一的問題是“資料”將涉及為每個請求建立和拆除會話。 將“內容”抽象到應用程序（可以保持單個會話處於活動狀態並處理來自Web服務的請求）是否似乎是正確的做法？ （如果是，則采用哪種通信方式）

工作時間可以忽略不計，我擔心的是，如果我為每個作業創建/刪除會話，則可能會對相關事務服務器產生沖擊。

某種形式的IPC或基於套接字的通信在這里可行嗎？

的想法/評論/經驗，不勝感激。

編輯：經過更多研究，似乎在Windows Service中托管WCF服務可能是一種更好的方法。

Answer 1

好吧，我們開始：

• 不要為每個請求都設置新的通信通道。 客戶端/服務器端使用WCF實現，並確保客戶端不會為每個調用獲得新的procxy;）特別是使用HTTPS通道設置時，這樣做的代價很高。

• 不要撥打該服務；）那樣簡單-盡可能少撥打電話。 將粗略接口優化為不打很多電話。 允許分批結果。 例如，“ GetInvoice”可以是“ GetDocuments”-不僅返回發票，並獲取多個ID，還返回多個文檔。 30張發票清單將30個電話變成1個電話。否則，可以使用消息傳遞總線方法-我使用類似的方法，每個呼叫最多可以傳送1024條消息。

• 如果您有大量負載，請嘗試不使用Web服務。 使用WCF和NetTcp綁定（這是二進制的而不是使用HTTP，因此它不是Web服務）。 HTTP的開銷是巨大的-查找Google，有人進行了測試，我們說的net tcp有時快900倍左右。 特別是如果您工作量少並且失去了用戶，則可能會增加可伸縮性。 負數-您僅在客戶端上符合WCF，現在不再有“ Web Service”。

這幾乎是您所能做的。 損失不盡相同，但這是提高性能的方法;）如果純粹是IPC，請考慮使用命名管道，甚至不使用net.tcp-命名管道非常有效（在進程之間使用共享內存），但限於相同.NET實現中的計算機。