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