|
|
1
6
有了无限的连接,您可能会创建大量的线程。这意味着需要大量的处理,加上每个线程在默认情况下仅为堆消耗固定数量的内存(我认为这个数字是512kb 每线程 ,但这可能取决于平台)。 通过共用固定数量的线程并接受有限数量的客户端,您将确保在合理的时间段内为某些客户端提供服务,并且您的服务器不会因过载而崩溃。 你可能想退房 this article on building servers using NIO 或者查看诸如 Apache Mina . |
|
|
2
4
事实上你可能会。当您超载时,您需要保留足够的容量,以便在接受任何负载之前消除当前负载。把每个人的身体都拖慢到一个停顿点,这比拒绝连接更容易接受。 排队论认为,甜点的利用率约为70%。如果你的服务器将有一个稳定的负载高于那得到更快的硬件,直到它没有。 话虽如此,如果你期望数十万个连接,我会使用线程池或nio。如果您只期望数千个线程,那么每个连接一个线程是最简单的方法。 |
|
3
2
如果您接受无限的连接,并且您的处理速度不足以处理传入连接流,那么您的队列将填满—直到它到达一个点,在这个点上处理以前的请求需要很长时间,以至于大多数请求甚至不再对答案感兴趣,因为一旦你找到他们。 |
|
|
4
2
|
|
|
5
0
在我看来,你的选择2是唯一的出路。每个5-10K连接应该有一个固定的NIO选择器线程。但是没有什么可以延迟这个关键线程,所以使用demux在固定数量的固定线程之间分配工作。 而不是线程池 . 和一个mux来收集工作并回复客户。正如ejp所说,如果您的工作线程滞后,最终您将不得不断开连接 除非开始将消息转储到磁盘以使队列尽可能大 . 这样即使在高负载下,y也不会断开任何连接。你可以查一下 this article 详细解释了这一点,并给出了下图:
免责声明: 我是CoralQueue的开发者之一 |