ASP.NET和多线程最佳实践

Question

我正在研究ASP.NET项目，昨天我看到一段使用System.Threading.Thread将一些任务卸载到新线程的代码。该线程运行一些SQL语句并记录结果。

使用其他方法不是更好吗？例如，要有一个执行SQL批处理的Windows服务。然后网页将排队（通过WCF）。

一般来说，ASP.NET中多线程的最佳实践是什么？是否有合理使用线程/ TPL任务/等。在网页上？

Answer 1

我在ASP.NET中使用多线程时的想法：

1. ASP.NET会因为某些原因而回收AppDomain，例如您更改web.config或在一段时间内以避免内存泄漏。问题是你不知道回收的确切时间。长时间运行的线程不适合，因为当ASP.NET回收时，它会相应地关闭你的线程。这种情况的正确的方法是长时间运行的任务应该通过队列在后台进程上运行，就像你提到的那样。

2. 对于短跑和点火任务， TPL 或 async / await 是最合适的，因为它不会阻止线程池中的线程用于HTTP请求。

Answer 2

在我看来，这应该通过在数据库中提升某种标志和定期检查标志并启动作业的Windows服务来解决。如果作业太频繁，则应使用专用队列解决方案（MSMQ，RabbitMQ等）以避免数据库过载或表增长过快。我不认为通过WCF或其他任何东西直接与Windows服务通信是一个好主意，因为这可能会导致消息丢失。

有人说，有时项目需要在共享主机中运行，并且无法设置专用的Windows服务。在这种情况下，一个线程是可以接受的，一旦项目增长到足以拥有自己的服务器，就应该删除该线程。

我相信ASP.NET中的所有其他线程都是问题的标志，除了使用Tasks来表示异步操作，或者在极少数情况下你想要在web项目中并行执行计算但是你的项目非常少数并发用户（并发用户少于核心数）

为什么任务在ASP.NET中有用？

将Task用于异步操作的第一个原因是从.NET 4.5 async API返回任务:) 异步操作（不要与并行计算混淆）可能是Web服务调用，数据库调用等。它们可能对两件事有用：

1. 一次点燃其中几个，你的工作将花费相当于最长时间的工作。如果以连续（非异步）方式触发它们，它们将花费时间等于每个操作的时间总和，这显然更多。
2. 他们可以通过释放执行页面的线程 - Node.js样式来提高可伸缩性。 ASP.NET永远支持这一点，但在4.5版本中它非常容易使用。由于async / await，我会声称它比Node.js更容易。释放线程非常重要，因为您可以让它们等待，从而耗尽池中的线程。结果是，当有一定数量的用户时，您的网站变得很慢，尽管CPU使用率仅为30％，因为新请求正在队列中等待。如果增加线程池中的线程数，则需要支付恒定上下文切换的价格，而不是操作系统。在某些时候，您将获得100％的CPU使用率，但其中40％将用于上下文切换。您将增加吞吐量，但收益递减。很多线程也会增加内存占用。