Web Service中长时间进程的最佳设计

Question

我有一个关于如何在我继承的现有DotNet2 Web服务中最好地处理流程的设计问题。

此时的过程如下：

客户端

1. 用户通过来自客户端/服务器应用程序的Web服务调用启动新请求
2. 创建并保存到数据库的请求和任务。
3. 创建的新线程开始处理请求
4. 请求ID返回给客户端（客户端使用ID轮询）。

主题

1. 加载请求详细信息和多个任务
2. 对于每项任务，它通过其他服务请求XML（约等待2秒）
3. 将XML传递给其他服务进行处理（约等待3秒）
4. 重复直到所有任务完成
5. 标记请求已完成（客户端将知道已完成）

总体而言，对于6个任务的请求大约需要30秒。由于每个任务都是按顺序执行的，因此显然效率低下。

最好是在一个单独的线程上再次突破每个任务，然后当它们全部完成时将请求标记为已完成？

我的预留是我立即将线程数量复制到6-10倍（任务数量），并关注这将如何影响IIS。我估计如果我同时处理每个任务，我可以将正常的30秒调用减少到大约5秒，但是在负载下这个设计会受到影响吗？

目前的设计运行良好，用户对处理时间没有任何问题，但如果可能，我希望它能更快地运行。

这只是一个完全糟糕的设计，如果是这样，有更好的方法吗？目前我受限于目前的DotNet版本。

谢谢

Answer 1

如果您担心IIS性能，您可能希望将作业保留在IIS之外，因此我会考虑将任务排队并创建单独的服务来完成工作。这种方法可扩展性更高，因为您可以添加或删除前端IIS服务器或任务处理器以解决变化的负载。大规模系统肯定会执行前端服务器的处理。