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

Question

我们希望使用Windows Workflow引导我们的网络用户沿着导航路径前进。

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

到目前为止，我们的原型是使用WorkflowApplication和SQL Persistence Provider。这有效，但我们关注所有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存储。