ASP.NET MVC多线程,值得吗? [英] ASP.NET MVC Multi-Threading, is it worth it?

查看:356
本文介绍了ASP.NET MVC多线程,值得吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有点困惑,我的ASP.NET MVC应用程序将托管在服务器上,因此使它成为多线程有什么意义吗?例如,如果我希望一个线程执行我的翻译,这是一个好主意吗?有人可以向我详细说明吗?我对Web应用程序多线程与桌面应用程序多线程有点困惑.

I'm a bit confused, my ASP.NET MVC app will be hosted on a server, so is there any point in making it multi-threaded? For example, if I want one thread to execute my translations, is this a good idea? Can someone elaborate this to me please? I'm a bit confused with web apps multi-threading versus desktop apps multi-threading.

推荐答案

这有几件事.

首先,每个ASP.NET应用程序(无论是MVC还是其他方式)本质上都是多线程的:每个请求都将在单独的线程上处理,因此您会自动处于多线程情况下,必须在任何共享的情况下都考虑到这一点.访问数据(例如,静电等).

The first is that every ASP.NET application (MVC or otherwise) is inherently multi-threaded: Each request will be processed on a separate thread, so you are automatically in a multi-threading situation and must consider this with any shared access to data (e.g. statics, etc.).

另一个是,借助MVC,它特别容易编写异步控制器方法,例如:

Another is that with MVC its particularly easy to write asynchronous controller methods like:

public async Task<ActionResult> Index(int id)
{
  var model = await SomeMethodThatGetsModelAsync(id);
  return View(model);
}

现在,如果我们已经是多线程的,那为什么还要麻烦呢?好处是(具有讽刺意味的是)使用更少的线程.假定SomeMethodThatGetsModel(id)可能阻塞或以其他方式阻止线程,对SomeMethodThatGetsModelAsync(id)await允许当前线程处理另一个请求. Web服务器可以处理多少个请求的限制之一是它可以处理这些请求的线程数.释放线程,可以增加吞吐量.

Now, if we're already multi-threaded then why bother? The benefit is (ironically in a way) to use fewer threads. Assuming that SomeMethodThatGetsModel(id) may block or otherwise hold up the thread, awaiting on SomeMethodThatGetsModelAsync(id) allows the current thread to handle another request. One of the limits on how many requests a webserver can handle is how many threads it can have handling those requests. Free up threads and you increase your throughput.

另外,您可能希望在整个应用程序的后台进行某些操作,原因与台式机应用程序相同.

A further is that you may want some operation to happen in the background of the application as a whole, here the reason is the same as with desktop applications.

简单地说,如果您有可以同时完成的工作并且阻塞了(例如打入数据库和两个Web服务),那么您采用多线程方式进行工作的原因与台式机应用程序相同.

Simpilarly, if you have work that can be done simultaneously and which blocks (e.g. hit a database and two webservices) then your reason for doing so in a multi-threaded manner is the same as with a desktop app.

(不过,在最后两种情况下,请谨慎使用默认的静态线程池,例如通过ThreadPool.QueueUserWorkItemTask.Run.因为如果您单击它,则该线程池将用于主ASP.NET线程.如果您大量使用单独的线程,则可以使用单独的一组线程(也许使用您自己的缓冲机制),这绝对是可以的,但是如果您大量使用单独的线程,则可以为它们使用单​​独的一组线程.

(In the last two cases though, be wary of using the default static thread pool, such as through ThreadPool.QueueUserWorkItem or Task.Run. Because this same thread pool is used for the main ASP.NET threads if you hit it heavily you're eating from the same plate as your framework. A few such uses is absolutely fine, but if you're making heavy use of separate threads then use a separate set of threads for them, perhaps with your own pooling mechanism).

这篇关于ASP.NET MVC多线程,值得吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆