asp.net – ThreadPools vs Own Threads用于长时间运行的进程

发布时间：2020-12-16 03:20:13 所属栏目：asp.Net 来源：网络整理

导读：我们有一些长期运行的业务流程,这些流程是通过在WS 2008 R2上以IIS(集成模式)运行的WCF服务启动的.这些业务流程通常涉及与SQL Server后端的大量交互.我们创建了一个自定义任务队列实现,通过初始服务调用将请求排队,然后根据优先级执行.此执行可能需要很长时

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

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

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

解决方法

这不完全是你所要求的 – 但为什么不在一个单独的进程(比如说windows服务)中一起执行你长时间运行的任务 – 无论如何构建一个优先级队列,客户端将在稍后的某个时间查询结果.我会采用这种方法,前端WCF服务将请求排队并响应状态更新查询,而后台服务将继续提供请求.这甚至允许工人进程回收等,而不用担心终止当前正在执行的任务.我看到的唯一问题是流程外通信的开销,但与任务所花费的时间(因为它们长时间运行)相比,它应该是微不足道的.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!