我有一些学生正在帮助我使用流媒体服务器。他们使用同步套接字和每个客户端一个线程，这不是很有效。最好使用异步方法让.Net利用IOCP。
问题是我并没有真正花时间思考什么时候异步套接字比单线程/套接字类型的架构更高效。 IIRC 最有效的两个每个核心有两个线程？
任何人都可以对此有所了解吗？异步套接字什么时候变得更高效？每个内核的最佳线程数是多少？
【问题讨论】：
标签： .net multithreading performance sockets
这取决于应用程序。如果您有 1000 个线程在等待磁盘或网络 I/O，或者有 10 个线程在进行计算…… 无论如何，事件驱动的设计效率更高，每个 CPU 没有线程和一个进程（如果有超线程，则为虚拟 CPU）。 观察您的应用程序的行为并相应地调整线程数。
【讨论】：
异步套接字总是更有效。
同步和异步套接字的区别在于异步套接字使用I/O completion ports而不是阻塞线程。与根本没有线程相比，阻塞的线程会消耗额外的资源，主要是内存。
关于每个内核的线程数的说法是错误的。
最有效的线程数是每个内核一个执行线程。不多不少。在您使用同步解决方案的情况下，线程在等待数据时将被阻塞（因此不在 CPU 上执行）。在异步解决方案中，在等待数据时也不会在 CPU 上执行线程（但阻塞的线程会更少）。两种情况下执行线程的数量相同，但异步会使用更少的内存开销。
编辑：
关于每个内核只有一个执行线程的一些说明。
更多的线程会给你上下文切换开销，更少的线程会让一些核心空闲。
但是，当涉及 I/O 时，要真正达到理想的线程数是一项艰巨的任务，因为线程并非一直都很忙。因此，如果您有等待 I/O 的线程阻塞，您可以拥有比内核更多的线程，但您应该尝试平衡线程的过度配置，以便每个内核始终有接近一个线程实际执行。
编辑 2：
再来一注。不要在意低负载时的效率，比如一两个客户端（除非这是实际的用户数量），优化尽可能高的负载，这时候性能很重要。
【讨论】：
标准的“一核一线程”在这里不适用。线程做了大量等待慢速连接和 I/O 完成的工作。由于涉及套接字的线程通常很少做任何实际工作，因此使用异步套接字很快就会成为一种胜利。
如果异步完成处理程序本身正在等待大量 I/O（可能是磁盘或 dbase），则这种情况会发生变化，线程池调度程序可能需要一段时间才能赶上尚未完成但尚未完成的工作人员燃烧循环。每秒仅添加两次额外的 TP 线程。
【讨论】：