我們正在將新應用程式部署到其實時環境。
應用程式伺服器正在執行 IIS 託管的 .NET 應用程序，該應用程式使用 EntityFramework 並對非 .NET COM+ 應用程式進行大量呼叫。
我們已經能夠透過修改 IIS 應用程式集區內的最大工作進程數來影響純 .NET 程式碼的效能，但我的問題是工作進程數與元件服務中應用程式集區的池大小有何關係？像：
- 我們是否應該以這兩個值之間的一對一關係為目標？
- 我們應該避免多個工作執行緒嗎？
任何見解感激不盡...
答案1
兩個池中的工作進程數量沒有直接關係。您需要確定的是每個池中的停留時間。因此，如果 IIS 工作執行緒很忙，並且只有一小部分時間花在 COM 應用程式上，那麼 COM 執行緒不太可能成為效能瓶頸。
嘗試測量壓力情況下的活動線程數，以確定如何控制各個池的大小。
也要考慮到 IIS 工作流程也會根據處理器使用率以外的標準進行回收。這可能會嚴重影響您在呼叫之間共享資料的能力，並可能破壞強烈影響直接效能的嘗試。
透過考慮使用可以聚合來自單一 .NET 查詢的多個請求的瘦 COM 包裝器，您可以更好地降低 .NET 到 COM 橋接的成本。這也可能產生將多個 COM 方法合併到池中的單一執行緒中的副作用。