Saj*_*jid 21 java linux multithreading nio nptl
我的Web服务器使用通常的Java I/O和每个连接机制.如今,他们越来越user with用户(长轮询连接).但是,连接大多是空闲的.虽然这可以通过添加更多的Web服务器来解决,但我一直在尝试对NIO实现进行一些研究.
我对它有一个复杂的印象.我已经读过基准测试,其中Linux中新的NPTL库的常规I/O 优于NIO.
使用Java I/O配置和使用最新的NPTL for Linux有什么真实的体验？有没有提高性能？
在更大范围的问题上:
在标准服务器类机器(带有四核处理器的戴尔)中我们希望正常执行的最大I/O和阻塞线程数(我们在Tomcat线程池中配置)是多少(使用Linux NPTL库？).如果线程池变得非常大,比如超过1000个线程会有什么影响？
任何参考和指针将非常感谢.
and*_*soj 17
挑衅性的博客帖子,"避免NIO,获得更好的吞吐量." Paul Tyma (2008)博客声称〜5000个线程没有任何麻烦; 我听说人们声称更多:
- 在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,那么CONSIDER会根据测量的性能需求转移到nio. 当我浏览谷歌搜索结果时,我很惊讶这几个资源实际上引用了任何(最近的)数字!
另外,请参阅Paul Tyma的演示幻灯片:旧的方式再次出现.基于他在谷歌的工作,具体数字表明同步线程I/O在Linux上具有相当大的可扩展性,并认为"NIO更快"是一段时间的真实,但不再是.彗星日报上有一些很好的补充评论.他引用了以下内容(轶事,仍然没有与基准测试相关的实际链接......)NPTL上的结果:
在测试中,NPTL成功地在两秒钟内在IA-32上启动了100,000个线程.相比之下,在没有NPTL的内核下进行此测试大约需要15分钟
如果你真的遇到了可扩展性问题,可能需要调整线程堆栈大小使用XX:ThreadStackSize.既然你提到Tomcat,请看这里.
最后,如果您受到约束并决定使用非阻塞I/O,请尽一切努力在知道他们正在做什么的人的基础上构建现有框架.我浪费了太多时间来试图获得一个错综复杂的非阻塞I/O解决方案(出于错误的原因).
另见SO相关内容.