使用Linux NPTL的Java I / O与Java新I / O（NIO）

Question

我的网络服务器使用通常的Java I / O和每个连接线程的机制。如今，他们越来越user with用户（长轮询连接）。但是，连接大多是空闲的。虽然这可以通过添加更多的Web服务器来解决，但我一直在尝试对NIO实现进行一些研究。

我对此印象很好。我已经读过基准测试，其中Linux中新的NPTL库的常规I / O优于NIO。

使用Java I / O配置和使用最新的NPTL for Linux有什么真实的体验？有没有提高性能？

在更大范围的问题上：

标准服务器类机器（带有四核处理器的戴尔）的I / O和阻塞线程（我们在Tomcat线程池中配置）的最大数量是多少？我们希望能够正常运行（使用Linux NPTL库？）。如果线程池变得非常大，比如超过1000个线程会有什么影响？

非常感谢任何参考和指针。

Answer 1

挑衅性的博客帖子，"Avoid NIO, get better throughput." Paul Tyma的(2008) blog声称〜5000线程没有任何麻烦;我听说人们声称更多：

  

  
1. 启用NPTL后，Sun和Blackwidow JVM 1.4.2可以轻松扩展到5000+   线程。阻挡模型是   始终比使用速度快25-35％   NIO选择器。很多技巧   EmberIO的人建议的是   雇用 - 使用多个选择器，   如果是第一个，则进行多次（2）读取   读取返回的EAGAIN等效物   Java的。然而，我们无法击败平原   Linux的每个连接模型的线程   NPTL。
  

我认为这里的关键是measure the overhead and performance，只有当你知道自己需要并且能够证明有所改进时，才能转向非阻塞I / O.编写和维护非阻塞代码的额外工作应该考虑在内。我的观点是，如果你的应用程序可以使用同步/阻塞I / O干净地表达，那就是。如果您的应用程序适用于非阻塞I / O，您不仅会在应用程序空间中重新发明阻塞I / O，而是根据测量的性能需求考虑转移到nio 。 当我浏览谷歌搜索结果时，我很惊讶，实际上很少有资源引用任何（最近的）数字！

另外，请参阅Paul Tyma's presentation slides：旧的方式再次出现。基于他在谷歌的工作，具体的数字表明同步线程I / O在Linux上具有很强的可扩展性，并认为“NIO更快”是一段时间的真实，但不再是。一些好的额外评论here on Comet Daily。他引用了以下内容（轶事，仍然没有与基准等相关的实际链接......）NPTL的结果：

  

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

如果您确实遇到了可扩展性问题，可能需要tune the thread stack size使用XX:ThreadStackSize。您提到Tomcat see here。

最后，如果您受到约束并决定使用非阻塞I / O，请尽一切努力构建existing framework by people who know what they're doing。我浪费了太多时间来试图获得一个错综复杂的非阻塞I / O解决方案（出于错误的原因）。

另见related on SO。

Answer 2

您可能会发现有用的链接：

• Handling of 100.000+ open connections
• The C10K problem
• Scalable Network Programming

您也可以查看http://nodejs.org/这不是JVM技术，但可以完美处理成千上万的连接（如果我没弄错的话，在幕后使用NPTL）

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

• Project Grizzly (Glassfish subproject)
• Netty
• Apache MINA

Answer 3

萨杰德，我看到你在做彗星（长期投票）。

几乎没有人谈论在NIO中为Comet事件执行用户代码的问题。 NIO线程调度Comet事件调用你的代码，如果你的代码不够好你就阻止了这个关键线程和其他Comet连接必须等待，因为NIO线程正在对SO的线程调度程序做类似的工作。这不是Comet with IO中的问题因为该线程仅适用于您的Comet事件/任务，并且调度程序可以在需要时放弃您的线程（使用NIO方法不那么容易）。

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