跨服务器场的Web用户的WF工作流程？

Question

我们希望使用Windows Workflow来指导我们的网络用户下载导航路径。

我们有一个服务器场，因此这转换为每个用户长时间运行的工作流程;多台服务器必须知道这一点。

到目前为止我们的原型是使用WorkflowApplication和SQL持久性提供程序。这有效，但我们关心所有的SQL Server活动及其性能。

我们发现有人创建了一个AppFabric缓存持久性提供程序（blog post here），这对我们很有吸引力，因为它意味着将我们的工作流程提供给RAM而不是SQL;但他们明确表示，它没有经过生产测试。

任何建议，想法或建议？

Answer 1

不幸的是，与大多数与性能相关的问题一样，除此之外没有什么好的答案：用真实世界的场景进行测试并看看。

我们对购物车风格工作流使用纯粹的SQL持久性，并且其性能没有问题。我们甚至提取了几个提升的属性，增加了一些存储开销但是，我的负载不是您的负载，我的工作流程不是您的工作流程，因此这并不意味着它可以在您的方案中正常工作。

我给出一个web场景的建议是确保将sqlWorkflowInstanceStore/@instanceLockedExceptionAction属性设置为AggressiveRetry。原因是在农场场景中，通常会有请求被路由到diff的模式。因此，如果两个呼叫快速连续进入，则工作流的第一个请求可能会发送到服务器A，而第二个请求会发送到服务器B.服务器A可能已经做出响应，但由于持久性与响应异步，因此可能会在第二次调用进入服务器B时仍然存在。服务器B可能无法第一次获得锁，因为服务器A正在完成持久性，因此它将进入重试例程。如果你没有指定AggressiveRetry，那么将会使用BasicRetry，它将使用非常缓慢的线性算法，该算法将表现为您的工作流的可怕服务性能。另一方面，AggressiveRetry将使用一种算法来“回退”更多的失败。由于赔率是服务器A即将完成，你通常会在前几次尝试中获得锁定。

就AppFabric Cache实现而言，我不会亲自使用该确切的实现，因为它不保证任何持久性。缓存可能会关闭，缓存可能需要清除其LRU对象，其中可能包括您的工作流实例等。如果有的话，我会推荐一个缓存通读实现，其中所有写/锁调用都是针对SQL完成的，但是反序列化工作流的实际数据可能会从缓存中提取出来。这显然不会有太大的影响，但是......比从SQL服务器读取更好。另一种可能性是AppFabric Cache 1.1添加了缓存读/写提供程序。因此，现在理论上您可以使用上面链接的缓存读/写直通提供程序实现，它实际上使SQL存储调用在底层之下，并且从应用程序的角度来看可能具有两全其美的优点，因为它只会处理缓存并且提供者将异步地写入SQL存储。