我们正在为数百名用户开发Asp.Net MVC 4中的Web应用程序。
我们需要有一个后台服务每个用户才能在几分钟的时间内工作。
我们不确定是使用Windows Services（多个Windows服务）还是使用线程池进程。我们认为Windows服务可以通过Windows服务器轻松维护，这种方法可以节省编程UI和管理线程的开销。它也可以在一段时间内轻松运行。
Windows Service是否可以为刚刚注册的新用户自动启动新实例（因此我们有多个后台Windows服务实例，每个用户一个）？如果不是Windows Services选项，那么
如果可以选择上限，我们是应该选择Windows Services方法还是制作我们自己的托管Thread Pool流程？
答案 0 :(得分：2)
当然，每个用户启动一个进程可以保证在进入1000s时你有很高的内存开销和不可扩展性。我不知道启动进程（而不是线程）可能会保存什么，因为新进程将包含至少一个线程。此外，Windows服务与＆＃34;登录用户＆＃34;无关。它们不是为多实例而制作的。
You seem to want to run background work in ASP.NET MVC.请注意，这很难。使用一个 Windows服务可以在这里有意义。
后台工作的难点在于工作进程可能因多种原因而退出。你必须容忍这一点。服务具有相同的问题：您需要部署新版本并定期重新启动服务器。您还需要一个HA策略，因此您需要多个服务器。
即使对于长时间运行的后台工作，我也不相信Windows服务会是更好的选择。
对于100个并发后台工作程序，您应该使用异步IO来使100个线程不专用。
我认为你的背景工作大部分时间都在等待。您可以使等待异步（使用计时器）和其他所有同步。这为您提供了简单的实现，并大大节省了内存使用量。
答案 1 :(得分：0)
使用单独的服务执行后台任务可能会带来额外的负担：
拥有两个独立的应用程序肯定会增加项目的复杂性：如果您需要在Web应用程序和服务之间进行任何通信，那么将整个内容放在Web应用程序中会更复杂（也更慢）。您还需要部署两个单独的项目，因此有一些管道开销会以这种方式加倍。
从性能方面来说，这种方法没有任何好处。相反，在Web应用程序中拥有自己的托管池将允许更好地安排这些线程，并且很可能允许您更有效地运行它们，而不仅仅是让Windows处理这个问题。你真的不想产生数百个在同一台机器上同时竞争资源的进程（或线程）。
如果不出意外，将整个功能保留在Web应用程序应用程序中可能会简化您的托管选项。安装和管理Windows服务可能需要比廉价主机提供商准备提供的更多权限。
话虽如此，在ASP.NET中运行后台任务意味着您需要准备好让您的线程突然中止，因为异常，回收或IIS可以想到的任何其他原因。在一个单独的进程中运行这些后台任务肯定不会受到这些ASP.NET怪癖的影响，因此它最终归结为一个妥协：确保这些任务永远不会被中断的重要性，以及它是否有理由进行额外的编程和维护工作？
<强> [编辑]
如果您关心如何在服务中安排这些任务，请查看.NET的一些调度库，例如Quartz。它允许更好地控制调度，而不仅仅是使用计时器（如果你需要它们）提供一些高级功能，如保持作业（如果你想确保你的工作在重新启动后完成），以及为大规模应用程序集群，那么它很有用。 p>
使用简单的计时器可以正常工作，但请确保您了解每个.NET计时器如何调度其事件。
答案 2 :(得分：0)
我们编写了一个开源项目Revalee来处理这种类型的工作负载。它使用Windows服务来管理任务调度，但利用现有的ASP.NET MVC应用程序来处理带外操作。任务可以达到数十万，并且在成功发送之前一直存在。
这是一个简单的工作流程图：
user initiated action
|
| ......................
| : future callback :
V V :
====================== ===========================
| Your web app | | Revalee Windows Service |
| | | |
====================== ===========================
| ^
| registers a callback now |
|________________________________|