Dynamics CRM 4.0 工作流程性能问题
我开发了一个工作流程，用于自动结束开始日期后 28 天的约会。为此，我创建了一个组织范围的工作流，使用工作流超时活动等待开始日期后 28 天后再关闭。
我担心，随着预约数量的增加，这可能会给 CRM 实施带来越来越大的负担（可能会打开数千个预约，并附加等待工作流程）。
我怎样才能检查这个？有谁知道异步服务多久会轮询一次以检查是否已达到超时，以及它对打开活动的数量有很大影响吗？
I have developed a workflow for automatically closing appointments that are 28 days past the start date. To do this I have created a organisation scoped workflow using a Workflow timeout activity to wait until 28 days after the start date before closing.
I am concerned that this may place an increasingly large load on the CRM implementation as the number of appointments increases (thousands could be open with waiting workflows attached).
How can I check this? does anyone know how often the async service will poll to check whether the timeout has been reached, and does it make a lot of difference on the number of open activities?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
数千个待处理/等待工作流程不是问题，现在如果它超过了百万个记录大关，那么您可能会遇到问题。您必须监视的最重要的事情是您的异步操作表。如果您的表增长超过 1-200 万个大关，并且工作流的创建速度快于异步服务处理它们的速度，您可能会发现性能受到影响。您可以采取一些措施来提高性能并防止表增长失控：
以下工作清除任何
处理记录并重建
必要时索引/统计。
KB968520
除此之外，您应该处于良好状态。
Thousands of pending/waiting workflows isn't an issue, now if it passes the million record mark then you might have issues. The big thing you have to monitor is your asyncoperation table. You'll probably see a performance hit if your table grows passed the 1-2 Million mark and the workflows are being created faster than the async service can process them. There are a few things you can do to improve performance and prevent the table growing out of control:
following job to clear out any
processed records and rebuild
indexes/statistics as necessary.
KB968520
Other than that you should be in good shape.
使用 KB968520 中的作业的技术是可以的，但更好的做法是创建“自我监管”工作流程，如果不采取它们导致的操作，该工作流程将在适当的时间（无论适合您的数据库的时间）自行过期。这使用了一种称为“并行等待条件”的技术，此处对此进行了讨论。
并行等待将强制工作流“清理”，即使它们影响的记录（或受它们影响的记录）已从数据库中删除。
The technique of using the job in KB968520 is OK, but it's better practice to create "self-policing" workflows, that will expire themselves in an appropriate time (whatever is appropriate for your db) if the actions they lead to aren't taken. This uses a technique known as a 'Parallel Wait Condition' and is discussed here.
Parallel wait's will force workflows to "clean up" even when the records they affect (or which they are affected by) have been removed from the database.