Windows「系統服務」，而不是「web服務」性能

Question

我們有一個圖像處理工作流產品。通常可以通過我們在工作中的處理來運行10,000-> 100,000個圖像。不止一項工作可能正在等待。

目前，在我們本土圖像庫，託管的C++庫，.N​​ET兼容執行所有的圖像處理。它在用戶的應用程序空間中運行。我的意思是，如果你登錄爲「PeteSmith」，圖片將在Pete Smiths的賬戶上運行。

目前，我們一次只允許一次圖像處理實例。客戶要求我們提供新版本，允許同時運行多個實例，因此我們現在正在研究如何做到這一點。

得到處理掉的想法「用戶佔」和使用「系統帳戶」做背景的處理是有吸引力。這很吸引人，因爲windows服務通過操作系統事件自然管理，如登錄和註銷以及其他系統資源利用事件警報。

在我看來，所有我們需要做的是管理少數明確定義的事件，微軟有據可查的。 這很好，很棒。但是，我需要了解的是，從客戶的角度來看，我們的圖像處理代碼的服務植入意味着性能。 在他們看來，他們需要更多的處理，更快。

的問題，我應該如何思考tradoffs：

1）使用服務來運行作業與運行N個不同的「實例」只在皮特·史密斯（用戶的）帳戶運行的軟件？

2）服務允許N個運行在比較N個不同的工作（不需要串擾）運行N個不同的「實例」只在皮特·史密斯（用戶的）帳戶運行的軟件？

Answer 1

那麼，圖像處理需要一定數量的CPU和IO資源來處理。通過擺脫開始流程的方式和位置，這一數量不會發生變化。

服務與否之間的差異應該由所需的使用模式來管理。如果您希望應用程序繼續自動處理圖像，而不管是否有人登錄，則應作爲服務運行，但如果使用更像「選擇圖像，開始處理並等待結果」樣式，則應該爲客戶端應用。

這並不完全清楚爲什麼你的客戶想要運行多個實例。是否因爲他們希望有一個實例在爲另一個實例配置處理時執行繁重的處理工作？還是他們想運行多個實例，因爲處理過程繁重，他們想要並行運行多個實例？

在這兩個，我會考慮運行在應用後臺線程的計算（一個或多個）的情況。如果不可能使用線程（可能是由於庫中的某些全局共享狀態），我的第二好選擇是在新進程中開始每個處理並等待主進程的結果。