小编典典

Java I / O与带有Linux NPTL的Java新I / O(NIO)

linux

我的Web服务器使用通常的Java I/O和每个连接机制的线程。如今,随着用户的增加(长时间的轮询连接),他们开始屈服。但是,连接大部分处于空闲状态。尽管可以通过添加更多的Web服务器来解决此问题,但我一直在尝试对NIO实现进行一些研究。

我对此有好感。我已经阅读了基准测试,其中使用Linux中新的NPTL库的常规I
/ O 优于NIO。

通过Java I / O配置和使用最新的NPTL for Linux的真实生活体验是什么?有提高的表现吗?

在更大范围的问题上:

在我们期望正常运行(使用LinuxNPTL库)的标准服务器类计算机(具有四核处理器的Dell)中,最大I/O和阻塞线程(我们在Tomcat线程池中配置)的最大数量是多少?如果线程池真的很大,比如说有1000多个线程,会产生什么影响?

任何引用和指针将不胜感激。


阅读 266

收藏
2020-06-07

共1个答案

小编典典

挑衅性的博客文章 “避免NIO,获得更好的吞吐量”。保罗·泰玛)2008)的博客声称〜5000个线程没有任何麻烦;我听说人们要求更多:

  1. 启用NPTL后,Sun和Blackwidow JVM
    1.4.2可以轻松扩展到5000+线程。阻塞模型始终比使用NIO选择器快25-35%。采用了EmberIO人士建议的许多技术-
    使用多个选择器,如果第一次读取返回Java中等效的EAGAIN,则执行多个(2)读取。但是,我们无法使用Linux NPTL击败每个连接模型的普通线程。

我认为这里的关键是 衡量开销和性能 ,并仅在您知道需要并且可以证明有改善时才转向非阻塞I /
O。编写和维护非阻塞代码的额外工作应纳入您的决定。我的看法是, 如果可以使用同步/阻塞I / O清晰地表达您的应用程序请执行该操作
。如果您的应用程序适合非阻塞I / O,而您不会只是在应用程序空间中严重地重新发明了阻塞I / O,请根据测得的性能需求 考虑使用nio
当我在google结果中四处搜寻时,我感到非常惊讶,实际上很少有资源引用任何(最新)数字

另外,请参阅PaulTyma的演示幻灯片:旧方法又是新方法。根据他在Google的工作,具体数字表明,同步线程I/ O在Linux上具有相当的可扩展性,并且认为“
NIO更快”是一个神话,这种说法已经存在了一段时间了,但是不再是。在“彗星日报”上还有一些不错的评论。他引用了NPTL上的以下结果(传闻,仍然没有到基准的牢固链接,等等…):

在测试中,NPTL在两秒钟内成功启动了IA-32上的100,000个线程。相比之下,在没有NPTL的内核下进行的测试大约需要15分钟

如果你真的遇到了可扩展性问题,可能需要调整线程堆栈大小使用XX:ThreadStackSize。由于您提到Tomcat,请参见此处

最后,如果您被束缚并决心使用非阻塞I /
O,则由知道自己在做什么的人尽一切努力在现有框架上进行构建。我浪费了太多时间来尝试获得正确的非阻塞I
/ O解决方案(由于错误的原因)。

2020-06-07