多实例性能问题
我在我的项目中使用Windows Workflow 4.0版本来管理工作流程。系统中创建一个项目，有100个文档需要用户审批，每个文档都应遵循相同的工作流程。 100 个文档的文档处理是并行的。哪个完成就可以进入下一个工作流程步骤。 [例如：文档创建 - 发送供审阅 - 已审阅 - 已批准]。
现在我正在为 100 个文档创建 100 个实例。但我不确定当文档显着增加时的性能（例如：10000 个文档）。还可以在任何给定时间点在系统中创建多个项目。
有没有更好的方法来处理这种情况？
该应用程序基于 ASP.Net 并运行 IIS。
I am using windows workflow 4.0 version in my project to manage workflow. One project gets created in the system which has 100 documents to be approved by users and each document should follow same workflow process. The document processing is parallel for 100 documents. Which ever finishes can go to the next workflow step.
[Eg: Document Created - Send for Review - Reviewed - Approved].
Now I am creating 100 instances for 100 documents. But I am not sure about performance when the documents are getting increased phenomenally (Eg: 10000 documents). Also multiple project can be created in the system at any given point of time.
Is there any better way to handle this scenario?
The application is based on ASP.Net and running IIS.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您的工作流程步骤（文档创建 - 发送以供审核 - 已审核 - 已批准）听起来像是涉及人类交互，这意味着它们将按照人类时间尺度进行。最短需要几分钟，更有可能是几个小时或几天。 Workflow 4.0 在设计时就考虑到了这种用例，因为未主动进行的实例将被持久保存到数据库存储中。扩展到数十个或数千个实例应该不成问题。
Your workflow steps (Document Created - Send for Review - Reviewed - Approved) sound like they involve human interactions, meaning they'll proceed at human time scales. Minutes at a minimum, more likely hours or days. Workflow 4.0 is designed with this use case in mind, as instances that are not actively progressing will be persisted out to your database store. Scaling to the 10s of thousands of instances should not be a problem.
您可以批量操作这些项目，也可以实时操作这些项目。需要考虑的问题是该过程需要有多实时。与每秒 100-1000 WF 的开销相比，每分钟执行一个批处理工作流程（接近实时）是否足够？
您肯定需要考虑设计的开销（实时可扩展性将是一个问题），因此，如果您的数量显着增加，您可能需要重新考虑所采用的实时方法。我的目标是采用批量方法以预先配置的频率轮询并使用
DelayActivity。You could operate the items in a batch process or as you have in realtime. The issues to consider is how real-time does the process need to be. Can it be sufficient to execute a batch workflow every minute (near realtime) as opposed to the overhead of 100-1000 WF per second?
You definitely need to consider the overhead of your design (realtime scalability will be an issue), so you may want to reconsider the realtime approach you have if your volume should increase significantly. I would aim for a batched approach to poll at a preconfigured frequency and use a
DelayActivity.我无法帮助您优化场景，但您可以通过首先缓存活动（而不是每次加载 xaml 并创建实例），然后通过正确确定何时在内存中卸载实例来优化性能。
I cannot help you to optimize your scenario but you can optimize the performance by first caching the activities (instead of each time loading the xaml and creating an instance) and second by determining correctly when to unload the instances in memory.
如果您在 IIS 中使用 AppFabric（Windows 服务器）托管 WF，那么这不是问题。您描述的步骤意味着您的 WF 正在等待因某些人机交互而导致的时间延迟或消息。在这些事件发生之前，进程将处于空闲状态，这意味着在短暂的空闲超时后，它们将从内存中卸载。您可以像这样处理数百万个并发进程。
If you are hosting your WF using AppFabric (windows server) in IIS then this is not a problem. The steps you describe mean your WFs are waiting for time delays or messages resulting from some human interaction. The process will be idle until those events, which means after a small idle timeout, they will be unloaded from memory. You can handle millions of concurrent processes like this.