Windows服務將文件發送到Web Service瓶頸

Question

我有一個監視目錄的Windows服務，每當它檢測到新文件時，它都會將該文件發送到我的Web服務進行處理。 我現在已經注意到，使用Web服務請求發送文件變得有點瓶頸，所以我試圖弄清楚替代方案是什么？

我曾想過讓Windows服務直接進行處理（我理想情況下），但這不是一個選擇。 使用WCF會更好嗎？ 在90％的部署中，Web Service與Windows服務位於同一服務器上，但有10％位於不同服務器上。 只是不確定這里最好的方法是什么......

編輯：我將文件作為字節[]發送到Web服務，這是我想以某種方式加速。 所以我的問題是，使用其他方法有助於加快速度，例如使用WCF和不同的協議嗎？ 我知道總有一個開銷，但試圖盡量減少這個。

Answer 1

WCF和綁定：更改為WCF提供了一些可以在LAN中傳輸數據更有效的綁定，例如NetTcpBinding或Named Pipes（僅限本地）。 因此，如果您不想在應用程序中引入更大的更改，那么使用WCF是一個很好的步驟。

混合方法：但是，至少對於在同一台計算機上托管兩個組件的90％部署加速的最佳方法是在這些情況下刪除進程邊界。 如你所說，你已經考慮過了。 因此，如果放棄這個想法的原因是10％需要分布式安裝的部署：通過使用具有本地處理實現的接口和用於遠程傳輸的實現，您可以實現支持兩者的可配置方法場景（90％非常高效，10％至少不像以前那樣慢）。

縮小數據大小：另一種顯而易見的加速方法是在將文件內容傳輸到服務之前過濾或壓縮文件內容。

文件路徑而不是內容：據我了解您的環境，托管服務的計算機至少彼此接近（LAN，沒有防火牆問題，......）。 因此，將文件內容傳輸到服務，但是通知服務文件路徑並讓Web服務直接訪問文件也可能是一個可行的選擇。 雖然不是一個非常漂亮的方式，有某些缺點（例如，Web服務的帳戶必須能夠訪問該文件，路徑也必須可以從Web服務訪問），您至少可以擺脫文件的低效傳輸並替換使用為文件訪問而構建的協議。 此外，在兩個服務在同一台機器上運行的90％的安裝中，Web服務將進行非常快速的本地文件訪問。