Java I / O与使用Linux NPTL的Java新I / O(NIO)

我的web服务器使用通常的Java I / O和每个连接机制的线程。 现在,他们正在增加用户(长轮询连接)的膝盖。 但是,连接大多是空闲的。 虽然这可以通过添加更多的Web服务器来解决,但是我一直在努力对NIO实现进行一些研究。

我对此有了一个混合的印象。 我已经阅读了基准testing,其中Linux中的新NPTL库的常规I / O性能优于NIO。

用Java I / Oconfiguration和使用最新的NPTL for Linux的真实生活经验是什么? 有没有增加的performance?

而在一个更大的范围问题上:

在一个标准的服务器级机器(带有四核处理器的戴尔)中,我们希望正常运行(使用Linux NPTL库?)的I / O和阻塞线程(我们在Tomcat线程池中configuration的)的最大数量是多less? 如果线程池变得非常大,说1000多个线程会有什么影响?

任何引用和指针将非常感激。

Solutions Collecting From Web of "Java I / O与使用Linux NPTL的Java新I / O(NIO)"

挑衅的博客文章“避免NIO,获得更好的吞吐量”。 保罗·泰马( Paul Tyma) (2008)的博客宣称〜5000条线程没有任何问题; 我听到人们声称更多:

  1. 通过NPTL,Sun和Blackwidow JVM 1.4.2可轻松扩展到5000+个线程。 阻塞模型一直比使用NIO选择器快25-35%。 EmberIO所提供的许多技术都被使用 – 使用多个选择器,如果第一次读取返回EAGAIN相当于Java,则执行多个(2)读取。 但是我们无法用Linux NPTL打败每个连接模式的纯线程。

我认为这里的关键是衡量开销和性能 ,只有当你知道你需要并且可以证明一个改进的时候,才能进入非阻塞I / O。 编写和维护非阻塞代码的额外努力应该被考虑在你的决定中。 我的意思是, 如果您的应用程序可以使用同步/阻塞I / O干净地表达那么 。 如果您的应用程序适合于非阻塞I / O,并且不会在应用程序空间中重新发明阻塞I / O,请根据测量的性能需求转移到nio我很惊讶,当我捅到谷歌的结果这几个资源实际上引用任何(最近)的数字

另见Paul Tyma的幻灯片 :旧的方式又是新的。 根据他在Google的工作,具体的数字表明,同步线程I / O在Linux上是相当可扩展的,并且认为“NIO更快”是一段真实的神话,但不再是这样。 “彗星日报”还有一些很好的补充评论。 他引用了以下内容(轶事,与基准仍然没有牢固的联系等),导致NPTL:

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

如果您真的遇到了可伸缩性问题,那么您可能需要使用XX:ThreadStackSize 调整线程堆栈大小 。 既然你提到了Tomcat,请看这里 。

最后,如果你决定使用非阻塞I / O,尽一切努力在知道自己在做什么的人的基础上建立一个现有的框架 。 我浪费了太多的时间试图让错综复杂的非阻塞I / O解决方案正确(出于错误的原因)。

另见相关的SO 。

您可能会觉得有用的链接:

  • 处理100.000+打开的连接
  • C10K的问题
  • 可扩展网络编程

你也可以看一下http://nodejs.org/ ,它不是一个JVM技术,但完美地处理了数千个连接(如果我没有弄错的话,在后台使用NPTL)

JVM下一些经过验证的NIO Web框架:

  • 项目灰熊(Glassfish子项目)
  • 网状
  • Apache MINA

Sajid,我知道你在做Comet(长时间投票)。

几乎没有人会谈到在NIO中执行Comet事件的用户代码的问题。 NIO线程调度Comet事件调用你的代码,如果你的代码不够好,你将阻塞这个关键的线程和其他Comet连接必须等待,因为NIO线程正在对SO的线程调度器做类似的工作。 这不是彗星IO中的问题,因为线程仅用于您的Comet事件/任务,调度程序可以在需要时放弃线程(NIO方法不是那么容易)。

我看到“同步Comet”(基于IO)的唯一问题是线程堆栈的内存消耗。

我期望任何有足够内存的服务器可以很容易地处理成千上万的空闲线程,可能有数十万个。