我有30k多个活动设备通过TCP粘接会话从我的应用程序连接。每个请求都创建自己的线程，并开始接收和发送数据。每个请求大约需要20分钟才能通过网络发送完整的数据包。这意味着应用程序大约需要创建30K个线程。
问题是我的应用程序有时变得无响应，不发送和接收消息，它是随机发生的。我在这里读到每个进程中线程的最大限制是2000。我想知道保持30k+会话并等待新消息发送和接收是否是糟糕的设计?如何管理这样的负载?
我的假设/建议:
1:最多创建2000个线程会因为上下文切换而导致应用程序变慢吗?2:在任何时间点28000设备将在等待，因为工作线程限制?
系统信息:
- 64位
- 8个CPU内核
少用线程。请使用异步IO。我强烈建议使用Kestrel来托管它，使用"管道"。模型，它将为您处理线程、缓冲区管理和大多数TCP细微差别，因此您只需担心协议和应用程序代码。它的扩展远远超出了您的需求(尽管对于30k套接字，您可能希望开始使用多个端口，特别是在负载平衡器之后，由于短暂的端口耗尽)。Kestrel需要。net Core或更高版本，但同样的方法也可以在。net Framework上通过Pipelines.Sockets.Unofficial实现。在这个背景下，管道和红隼的一个指南是由4部分组成的系列，其他指南也可以在这里找到。