我在我的项目中使用 windows 工作流 4.0 版本来管理工作流。在系统中创建了一个项目，该项目有 100 个需要用户批准的文档，每个文档应遵循相同的工作流程。100 个文档的文档处理是并行的。哪一个完成可以进入下一个工作流程步骤。[例如：文档已创建 - 发送以供审核 - 已审核 - 已批准]。
现在我正在为 100 个文档创建 100 个实例。但是我不确定当文档显着增加时的性能（例如：10000 个文档）。也可以在任何给定时间点在系统中创建多个项目。
有没有更好的方法来处理这种情况？
该应用程序基于 ASP.Net 并运行 IIS。
您的工作流程步骤（创建文档 - 发送以供审核 - 已审核 - 批准）听起来像是涉及人工交互，这意味着它们将在人工时间尺度上进行。最少几分钟，更可能是几小时或几天。Workflow 4.0 的设计考虑到了这个用例，因为没有积极进行的实例将被持久化到您的数据库存储中。扩展到成千上万个实例应该不是问题。
我无法帮助您优化场景，但您可以通过首先缓存活动（而不是每次加载 xaml 并创建实例）来优化性能，然后通过正确确定何时卸载内存中的实例来优化性能。
您可以在批处理过程中或实时操作这些项目。需要考虑的问题是该过程的实时性如何。与每秒 100-1000 WF 的开销相比，每分钟（接近实时）执行批处理工作流程是否足够？
您肯定需要考虑设计的开销（实时可扩展性将是一个问题），因此如果您的体积应该显着增加，您可能需要重新考虑您拥有的实时方法。我的目标是采用批处理方法以预先配置的频率进行轮询并使用DelayActivity.
如果您在 IIS 中使用 AppFabric（Windows 服务器）托管您的 WF，那么这不是问题。您描述的步骤意味着您的 WF 正在等待时间延迟或某些人为交互导致的消息。在这些事件之前，进程将处于空闲状态，这意味着在一个小的空闲超时之后，它们将从内存中卸载。您可以像这样处理数百万个并发进程。