我们有一个带有 Search Server 的 WSS 3.0 安装，用于搜索文档并保存搜索定义以便稍后重复搜索。用户希望能够将搜索结果中的所有文件下载为一次性 Zip 文件。
我有一个非常基本的解决方案，当用户单击按钮时，文件的压缩是在 Web 部件中完成的，但是如果 zip 文件需要一段时间来创建用户等待（我怀疑，任何其他用户访问该站点将等待，因为我想文件的压缩是由 w3wp 进程完成的）。
我想也许我可以将 zip 文件创建作为一个工作流开始，一旦工作流完成，用户就可以下载文件，但我现在意识到工作流也在 w3wp 进程下运行。
如果工作流任务需要很长时间才能执行（例如，如果用户选择了要下载的大量文档），是否会影响 sharepoint 站点的其他用户并阻止他们访问任何页面，直到工作流完成？
显然，我们将对用户可以压缩下载的文件的最大大小设置一些限制，这样我们就不会杀死机器，但我仍然担心无论我们设置什么限制，工作流程仍然会结束锁定其他用户。是这样吗？有没有更好的建议来创建这样一个不会影响其他用户的任务？
谢谢
在创建 ZIP 的活动之前在工作流中放置一个延迟活动。这会将工作流从交互式 W3WP 流程推送到 WSSTimerV3 服务，因为它需要在未来运行。
问候，保罗
如果压缩时间少于 5 秒，我会在同一个线程中同步执行并完成它。最少的复杂性，最佳的用户体验，不会阻塞其他用户（受 ASP.NET 线程池大小的限制）。一堆点击会杀死服务器。
如果您有大文件或大量流量，您可以在数据库中保留一个先进先出队列，并让 Windows 服务将它们取出并执行它们。这样您就可以控制用于压缩文件的线程数。此解决方案为您提供 O(1) 算法复杂度，但大大增加了设计的复杂性。您可能需要考虑使用 AJAX 之类的东西来告诉用户“您是队列中 45 人中的 4 人......”。
如果您的文件大小变化很大，您可能希望将前两个解决方案作为策略实施，并通过查看解压缩文件大小和服务器资源可用性等因素来实施第三个自适应策略，该策略遵循前面提到的策略之一。用户体验和资源可用性之间的良好折衷，但最复杂（昂贵）。
格罗特，汉斯
即使您在 Web 部件中进行压缩，也不会阻止其他用户。处理请求的 w3wp 工作线程在等待 zip 完成时被阻塞，但所有其他工作线程都能够继续。
尽管如此，如果有许多等待 zip 线程，这可能会成为一个可伸缩性问题：最终，传入请求可能会阻塞等待工作线程可用。这就是在 ASP.NET 中使用异步处理的原因。
使用工作流会有所帮助，因为工作流已启动，请求已完成，允许处理其他请求。
您担心在 w3wp 中运行的工作流。但是，我不知道它是在 w3wp 中的一个工作线程上运行的。我不知道 SharePoint 如何配置其工作流主机，但我怀疑它使用了一组不同的线程。
您可能想要对此进行一些负载测试以找出答案。创建一个虚拟 Web 部件，只要您请求包含它的页面，它就会运行一个 zip。运行该页面的负载并找出在它们开始排队等待工作线程可用之前可以获得多少请求。然后做同样的事情，但让 Web 部件启动工作流。同样，查看在请求开始排队之前可以同时运行多少个请求。