多线程的web应用程序

Question

我知道有很多情况下，最好多线程的应用程序，但 什么时候最好多线程一个.net的web应用程序？

Answer 1

Web应用程序几乎可以肯定已经由宿主环境（IIS等）多线程化。如果你的页面是CPU限制的（并且想要使用多个内核），那么可以说多线程是一个坏主意，因为当你的系统处于负载下时，你已经在使用它们了。

它的时间它可能帮助是当你IO的约束;例如，您有一个需要与3个外部Web服务交谈的网页，与数据库交谈并编写一个文件（全部不相关）。您可以在不同线程上并行执行这些操作（理想情况下使用内置的异步操作，以最大限度地提高完成端口的使用率），以缩短总体处理时间 - 所有操作都不会对本地CPU造成太大影响（这里实际的延迟在网络上）。

当然，在这种情况下，您也可以通过简单地在Web应用程序中排队工作，并让单独的服务将它们出列并处理它们来做得更好，但是不能立即响应调用者需要稍后检查确认完成等）。

Answer 2

为了从多线程中受益，您的应用程序必须执行大量可并行运行的工作。如果情况并非如此，多线程的开销可能会带来好处。

根据我的经验，大多数Web应用程序都包含一些简短的运行方法，因此除了托管环境已经提供的并行性之外，我会说很少从Web应用程序的各个部分中的多线程中受益。有可能会提供一些好处的例子，但我的猜测是它并不常见。

Answer 3

恕我直言，你应该避免在基于Web的应用程序中使用多线程。

也许多线程应用程序可以提高标准应用程序的性能（使用正确的设计），但是在Web应用程序中，您可能希望保持高吞吐量而不是速度。

，但如果你有几个并发连接也许你可以使用并行线程没有一个全球性的性能下降

Answer 4

ASP.NET已经能够产卵几个线程并行处理多个请求的，所以对于简单的请求处理有当你需要手动产生另一个线程时，情况很少。不过，也有我所遇到这保证另一个线程创建了几个常见的场景：

• 如果有可能需要一段时间，并且可以在平行于页面处理的其余部分运行一些操作，你可能会在那里产生一个辅助线程。例如，如果有一个Web服务必须作为请求的结果进行轮询，则可能会在Page_Init中产生另一个线程，并检查Page_PreRender中的结果（如果需要，等待）。尽管这仍然是个问题，但这是否会带来性能上的好处 - 产生线程并不便宜，而且典型的Page_Init和Page_Prerender之间的时间无论如何都是以毫秒为单位来衡量的。为此保留一个线程池可能会更有效一些，而ASP.NET也有一些称为“异步页面”的东西，可能更适合这种需求。
• 如果有一个您希望定期清理的资源池。例如，假设你正在使用一些带有有限.NET绑定的奇怪DBMS，但没有池化支持（这是我的情况）。在这种情况下，你可能要自己实现数据库连接池，而这将需要一个“清理线程”，它就会醒来，比方说，一分钟一次，并检查是否有尚未被长期使用，而连接（和因此可以关闭）。

在ASP.NET中实现自己的线程时要记住的另一件事 - 如果ASP.NET在一段时间内一直处于非活动状态，它喜欢杀死它的进程。因此，你不应该依赖你的线程永远活着。它可能在任何时候被终止，你最好准备好。

Answer 5

多线程是这样一种技术，以提供一个单一的过程与更多的处理时间，以允许它运行得更快。它有更多的线程，因此它消耗更多的CPU周期。 （如果有的话，可以从多个CPU中获得）。对于桌面应用程序来说，这很有意义。但是，向Web用户授予更多的CPU周期将会从同时请求请求的99个其他用户那里获得相同的周期！从技术上讲，这是一件坏事。

然而，Web应用程序可能使用其他的服务和进程正在使用多个线程。例如，数据库不会为连接到它们的每个用户创建单独的线程。它们将线程数量限制为少数，将连接添加到连接池以加快使用率。只要有可用或汇集的连接，用户就可以访问数据库。当数据库用完连接时，用户将不得不等待。

因此，基本上，多个线程的使用可以用于Web应用程序，以减少特定时刻的活动用户数量！它允许系统与多个用户共享资源，而不会使资源过载。相反，用户在轮到他们之前必须排队。

这不会是Web应用程序本身的多线程，而是Web应用程序使用的服务中的多线程。在这种情况下，它被用作限制，只允许少量线程处于活动状态。