ThreadPools与自己的线程,用于长时间运行的进程

Question

我们有一些长期运行的业务流程,这些流程是通过在WS 2008 R2上以IIS(集成模式)运行的WCF服务启动的.这些业务流程通常涉及与SQL Server后端的大量交互.我们创建了一个自定义任务队列实现,通过初始服务调用将请求排队,然后根据优先级执行.此执行可能需要很长时间才能完成(极端20-30分钟).然后,客户端可以向服务器查询其自己的后台任务的进度.

在我们当前的实现中,任务在一个单独的线程上触发,而不是从ThreadPool执行.这是因为阅读了使用ThreadPool不运行长时间运行任务的建议,以防止使ASP.NET请求无法提供服务.我们通过对可以同时执行的后台任务的数量设置上限来控制生成的线程数.这样我们就可以尝试控制CPU上的负载并防止过多的线程上下文切换.虽然所有这一切都在发生,但我们当然仍然需要为应用程序提供正常的"在线"请求.

在阅读了Thomas Marquardt撰写的这篇文章后,我担心我们没有使用ThreadPool,因为我们无法获得内置调优启发式的好处.我们已经通过挂钩ApplicationEnd事件并取消长时间运行的任务来解决关闭问题.所以我的问题是,我们应该切换到使用ThreadPool吗？这些线程被长时间捆绑了怎么办？如果我正确理解Thomas,他说这无关紧要,因为ThreadPool会调整自己以创建更多请求以服务于正常的在线操作？我也读过这个覆盖相同理由的StackOverflow问题,但我仍然不确定前进的方向.

Answer 1

这并不完全是您所要求的 - 但为什么不在一个单独的进程（例如 Windows 服务）中一起执行长时间运行的任务 - 无论如何，您正在构建一个优先级队列，并且客户端将在一段时间后查询结果。我会采用这种方法，其中前端 WCF 服务对请求进行排队并响应状态更新查询，而后台服务将继续处理请求。这甚至允许工作进程回收等，而无需担心终止当前正在执行的任务。我看到的唯一问题是进程外通信的开销，但与任务所花费的时间相比（因为它们长时间运行），它应该是微不足道的。