我在我的項目中使用Windows工作流4.0版來管理工作流。在系統中創建了一個項目，該項目有100個文件需要用戶批准，每個文件都應遵循相同的工作流程。文檔處理對於100個文檔是並行的。哪個結束可以進入下一個工作流程步驟。 [例如：創建的文檔 - 發送審閱 - 審查 - 批准]。多實例性能問題
現在我正在爲100個文檔創建100個實例。但是當文件數量增加時（例如：10000份文件），我不確定表現如何。還可以在任何給定的時間點在系統中創建多個項目。
有沒有更好的方法來處理這種情況？
該應用程序基於ASP.Net並運行IIS。
您可以通過批處理或實時操作項目。需要考慮的問題是過程需要多長時間。每分鐘執行批處理工作流程（接近實時）是否足以實現每秒100-1000 WF的開銷？您需要考慮設計的開銷（實時可伸縮性將是問題），所以如果您的體積應該大幅增加，您可能需要重新考慮實時方法。我會針對以預先配置的頻率輪詢並使用DelayActivity的批量方法。
您的工作流程步驟（文檔創建 - 發送審覈 - 審覈 - 批准）聽起來像他們涉及人與人的互動，這意味着他們將在人類的時間尺度進行。至少需要幾分鐘，更可能是幾小時或幾天。考慮到這個用例，Workflow 4.0的設計就要考慮到這一點，因爲沒有積極進展的實例將被持久化到數據庫存儲中。縮放到數千個實例的數十個應該不成問題。
我無法幫助您優化您的場景，但您可以通過首先緩存活動（而不是每次加載xaml和創建實例）來優化性能，然後通過正確確定何時卸載內存中的實例來優化性能。
如果您在IIS中使用AppFabric（Windows服務器）託管您的WF，那麼這不是問題。您所描述的步驟意味着您的WF正在等待由於某些人際交互而導致的時間延遲或消息。這個過程將一直處於空閒狀態，直到這些事件發生，這意味着在一個小的空閒超時之後，它們將從內存中卸載。您可以像這樣處理數百萬個併發進程。