SignalR中心是自托管还是非自托管？

Question

我正在处理一个项目，其中一个SignalR中心启动了12个短时间运行的线程（new Thread()）。每个线程使用websockets在完成后向客户端报告。这些线程不会占用CPU，而是从其他Web服务获取一些信息。

现在我的困境是：我应该创建一个独立的自托管SignalR中心应用程序作为服务运行，还是只需将中心包含在我的asp.net MVC项目中即可？

从性能方面来看，哪种方法更好？

- Dimo

---

你不应该使用“多线程”。 - Aron

Damian Edwards和David Fowler在2013年NDC London上的演讲名为“Using ASP.NET SignalR.. in anger”，描述了您想要做的事情，并展示了示例代码。请参见http://vimeo.com/84677242，大约在27分钟处。 - Johan B

Answer 1

在 .net 4.5 及以上版本中，正确的做法是进行单线程异步操作。 ASP.Net绝不能创建新线程。在 ASP.Net 中显式使用线程会造成性能损失。

另外，需要知道的是，线程是有限 CPU 资源的抽象（你提到了你的线程不占用 CPU 资源）。在 .net 4.5及以上版本中，这意味着你不应该使用线程。相反，在这种情况下，你应该使用无线程 I/O API 来调用你的 Web 服务。我建议你使用 TAP 模式（即 async await），这基本上就是 .net 4.5。

这样可以让你的应用程序在一台中等配置的机器上扩展到处理数千个并发请求。

如果你已经实现了全部内容，并且使用了 TAP，那么 ASP.Net MVC/IIS 将与巨大的并行和“线程”相容。在这种情况下，我强烈建议不要使用 Windows 服务，因为 IIS 作为你的启动程序（处理 生命周期，并在服务死亡时重新启动它）会更加稳定。

- Aron

Answer 2

如果性能是一个问题，我会使用线程池而不是新的线程。我将把它托管在Windows服务中，因为这样可以更好地控制分配给线程的资源。

- Shachaf.Gortler

---

线程池使用线程池，所以我可能会使用TPL。有什么优点？那只是从线程池中使用线程... - Dimo

@Dimo 不是的。TPL 不使用线程池。TPL 不关心哪些任务需要并行处理。TPL 是一个抽象层和模式库。Task.Run (包含在 TPL 中) 使用 ThreadPool，而且坦白说，你几乎永远不应该使用 Task.Run。 - Aron