我们有一些长期运行的业务流程,这些流程是通过在WS 2008 R2上以IIS(集成模式)运行的WCF服务启动的.这些业务流程通常涉及与SQL Server后端的大量交互.我们创建了一个自定义任务队列实现,通过初始服务调用将请求排队,然后根据优先级执行.此执行可能需要很长时间才能完成(极端20-30分钟).然后,客户端可以向服务器查询其自己的后台任务的进度.
在我们当前的实现中,任务在一个单独的线程上触发,而不是从ThreadPool执行.这是因为阅读了使用ThreadPool不运行长时间运行任务的建议,以防止使ASP.NET请求无法提供服务.我们通过对可以同时执行的后台任务的数量设置上限来控制生成的线程数.这样我们就可以尝试控制CPU上的负载并防止过多的线程上下文切换.虽然所有这一切都在发生,但我们当然仍然需要为应用程序提供正常的"在线"请求.
在阅读了Thomas Marquardt撰写的这篇文章后,我担心我们没有使用ThreadPool,因为我们无法获得内置调优启发式的好处.我们已经通过挂钩ApplicationEnd事件并取消长时间运行的任务来解决关闭问题.所以我的问题是,我们应该切换到使用ThreadPool吗？这些线程被长时间捆绑了怎么办？如果我正确理解Thomas,他说这无关紧要,因为ThreadPool会调整自己以创建更多请求以服务于正常的在线操作？我也读过这个覆盖相同理由的StackOverflow问题,但我仍然不确定前进的方向.