我们希望使用 Windows 工作流来引导我们的网络用户沿着导航路径前进。
我们有一个服务器场，因此这意味着每个用户都有一个长期运行的工作流程；多个服务器必须知道的。
到目前为止，我们的原型是 WorkflowApplication 和 SQL Persistence Provider 的使用。这可行，但我们担心所有 SQL Server 活动及其性能。
我们发现有人创建了一个 AppFabric 缓存持久性提供程序 (blog post here)，这对我们很有吸引力，因为这意味着将我们的工作流混合到 RAM 而不是 SQL；但他们明确表示它没有经过生产测试。
有什么建议、想法或建议吗？
【问题讨论】：
标签： asp.net workflow-foundation-4
不幸的是，与大多数与性能相关的问题一样，除了使用您的真实场景进行测试并查看之外，没有其他好的答案。
我们将纯 SQL 持久性用于购物车样式的工作流，并且其性能没有问题。我们甚至提取了几个提升的属性，这增加了一些存储开销。但是，我的负载不是您的负载，我的工作流程也不是您的工作流程，因此并不意味着它适用于您的场景。
对于网络农场场景，我要给出的一个建议是，确保将sqlWorkflowInstanceStore/@instanceLockedExceptionAction 属性设置为AggressiveRetry。这样做的原因是，在农场场景中，通常您具有将请求路由到 diff 的模式。因此，如果两个调用连续快速进入，则工作流的第一个请求可能会发送到服务器 A，第二个请求可能会发送到服务器 B。服务器 A 可能已经响应，但由于持久性与响应异步，它可能当第二次调用进入服务器 B 时仍然保持不变。服务器 B 第一次可能不会获得锁，因为服务器 A 正在完成持久性，因此它将进入重试例程。如果您不指定AggressiveRetry，则将使用BasicRetry，它使用一种非常缓慢的线性算法，这将表现为您的工作流程看起来很糟糕的服务性能。另一方面，AggressiveRetry 将使用一种算法，该算法会“退出”它获得的失败越多。由于服务器 A 很快就会完成，因此您通常会在前几次尝试中获得锁定。
就 AppFabric 缓存实现而言，我个人不会使用该确切实现，因为它不能保证任何持久性。缓存可能会关闭，缓存可能需要清除其 LRU 对象，其中可能包括您的工作流实例等。如果有的话，我建议使用缓存通读实现，其中所有写入/锁定调用都是针对 SQL 完成的，但是用于反序列化工作流的实际数据可能来自缓存。这显然不会产生那么大的影响，但是......仍然比从 SQL 服务器读取要好。另一种可能性是 AppFabric Cache 1.1 添加了缓存读/写提供程序。因此，现在您理论上可以将上面链接的实现与缓存读/写提供程序实现结合使用，该实现实际上在幕后进行 SQL 存储调用，并且从应用程序的角度来看可能具有两全其美，因为它只会永远处理缓存，提供程序将异步写入 SQL 存储。
【讨论】：