Sharepoint 中长时间运行的工作流，它们是否会阻止 w3wp 进程答案

【问题标题】：Long Running Workflows in Sharepoint, do they block the w3wp processSharepoint 中长时间运行的工作流，它们是否会阻止 w3wp 进程
【发布时间】：2009-06-20 12:57:38
【问题描述】：

我们有一个带有搜索服务器的 WSS 3.0 安装，用于搜索文档并保存搜索定义以便稍后重复搜索。用户希望能够将搜索结果中的所有文件下载为一次性 Zip 文件。

我有一个非常基本的解决方案，当用户单击按钮时，文件的压缩在 Web 部件中完成，但如果 zip 文件需要一段时间来创建用户等待（我怀疑，任何访问该站点的其他用户将等待，因为我想文件的压缩是由 w3wp 进程完成的）。

我想也许我可以将 zip 文件创建作为一个工作流程开始，一旦工作流程完成，用户就可以下载文件，但我现在意识到工作流程也在 w3wp 流程下运行。

如果工作流任务需要很长时间才能执行（例如，如果用户选择了要下载的大量文档），它是否会影响 sharepoint 站点的其他用户并阻止他们访问任何页面，直到工作流完成完成了吗？

显然，我们将对用户可以压缩下载的文档的最大大小设置一些限制，这样我们就不会杀死机器，但我仍然担心我们设置的任何限制，工作流程最终仍可能锁定其他用户。是这样吗？有没有更好的建议来创建这样一个不会影响其他用户的任务？

谢谢

【问题讨论】：

标签： sharepoint workflow zip locking w3wp

【解决方案1】：

在创建 ZIP 的活动之前在工作流中放置一个延迟活动。这会将工作流从交互式 W3WP 流程推送到 WSSTimerV3 服务，因为它需要在未来运行。

问候，保罗

http://blogs.msdn.com/pandrew

【讨论】：

【解决方案2】：

即使您在 Web 部件中进行压缩，也不会阻止其他用户。处理请求的 w3wp 工作线程在等待 zip 完成时被阻塞，但所有其他工作线程都能够继续。

不过，如果有许多等待 zip 线程，这可能会成为可伸缩性问题：最终，传入请求可能会阻塞等待工作线程可用。这就是在 ASP.NET 中使用异步处理的原因。

使用工作流会有所帮助，因为工作流已启动，请求已完成，允许处理其他请求。

您担心在 w3wp 中运行的工作流程。但是，我不知道它是在 w3wp 中的一个工作线程上运行的。我不知道 SharePoint 如何配置其工作流主机，但我怀疑它使用了不同的线程集。

您可能希望对此进行一些负载测试以找出答案。创建一个虚拟 Web 部件，只要您请求包含它的页面，它就会立即运行一个 zip。运行该页面的负载并找出在它们开始排队等待工作线程可用之前可以获得多少请求。然后做同样的事情，但让 Web 部件启动工作流。同样，看看在请求开始排队之前您可以同时运行多少个请求。

【讨论】：

【解决方案3】：

如果压缩时间少于 5 秒，我会在同一个线程中同步执行并完成它。最少的复杂性，最佳的用户体验，不会阻塞其他用户（受 ASP.NET 线程池大小的限制）。一堆点击会杀死服务器。
如果您有大文件或大量流量，您可以在数据库中保留 先进先出 队列，并让 Windows 服务将它们取出并执行。这样您就可以控制用于压缩文件的线程数。此解决方案为您提供 O(1) 算法复杂度，但大大增加了设计的复杂性。您可能需要考虑使用 AJAX 之类的东西来告诉用户“您在队列中的 45 人中有 4 人......”。
如果您的文件大小变化很大，您可能希望将前两个解决方案作为策略实施，并实施第三种自适应策略，该策略通过查看解压缩文件大小和服务器资源可用性。用户体验和资源可用性之间的良好折衷，但最复杂（昂贵）。

格罗特，汉斯

【讨论】：