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