Undertow,Tomcat和Jetty服务器配置详解与性能测试
https://www.cnblogs.com/maybo/p/7784687.html
1总概：
undertow,jetty和tomcat可以说是javaweb项目当下最火的三款服务器，tomcat是apache下的一款重量级的服务器。当下微服务兴起，spring boot ，spring cloud 越来越热的情况下，选择一款轻量级而性能优越的服务器是必要的选择。spring boot 完美集成了tomcat，jetty和undertow
jetty和undertow都是基于NIO实现的高并发轻量级的服务器，支持servlet3.1和websocket。
1.1NIO(非阻塞式输入输出)
- Channel
- Selector
- Buffer
- Acceptor
Client和Server只向Buffer读写数据不关注数据的流向，数据通过Channel通道进行流转。而Selector是存在与服务端的，用于Channel的注册以此实现数据I/O操作。Acceptor负责接受所以的连接通道并且注册到Channel中。而整个过程客户端与服务端是非阻塞的也就是异步操作
1.2Jetty和Undertow主要配置
对于服务器端而言我们关心的重点不是连接超时时间，socket超时时间以及任务的超时时间等的配置，重点是线程池设置，包括工作线程，I/O线程的分配。Jetty在这方面似乎有点太随意，全局使用一个线程池QueuedThreadPool,而最小线程数8最大200，Acceptor线程默认1个，Selector线程数默认2个。而Undertow就比较合理点，Acceptor通过递归循环注册，而用于I/O的线程默认是cpu的线程数，而工作线程是cpu线程数*8。
无论设计架构如何可以看到两个服务器都是基于NIO实现的，而且都有通过Selector来执行所有的I/O操作，通过IP的hash来将Channel放入不同的WorkThread或SelectorManager中，然后具体的处理工作有线程池来完成。所有，我个人认为Jetty的selectors数和Undertow的IOThreads数都是用于Selector或说是做I/O操作的线程数。不同的是Jetty全局线程池。而对于两个服务器的承载能力以及读写效率，包括LifeCycle过程的管理等，决定了两个服务器性能的好坏。毕竟用于工作的线程所有的开销在于业务，所有个人觉得：I/O操作，管理与监听，决定了两个服务器的优劣
1.3Jetty和Undertow压测分析
小数据量测试：
在高负载下Undertow的吞吐量高于Jetty而且随着压力增大Jetty和Undertow成功率差距会拉大。而在负载不是太大情况下服务器处理能力差不多，jetty还略微高于Undertow。而tomcat的负载能力似乎和Undertow很接近。
对比三个服务器发现在Undertow在负载过重情况下比Jetty和Tocmat更加顽强，实践证明在负载继续加大情况下Undertow的成功率高于其它两者，但是在并发不是太大情况下三款服务器整体来看差别不大。
大数据量测试：（1892byte）
Undertow和Tomcat的负载能力很接近但是Undertow比较好点，而Jetty远远不足。通过观察以上三张图不难发现，Undertow的I/O线程执行100% , Tomcat的执行也是100%两者不同的是Undertow用于I/O的线程数是可以调整的，而Tomcat不可以，起码通过spring boot 无法调整，这样就制约了它的负载能力。而Jetty由于全局共享线程池所以，会存在Selector和Acceptor阻塞情况，这样就制约了I/O操作。但是有个好处就是在负载不是太重的情况下可以使工作线程有更多占用资源来处理程序，提高了吞吐量。