相对tomcat，undertow目前用的人越来越多。我们之前用tomcat时候一般都采用默认配置，承受的并发也不低。但是如果改为undertow这些配置必须不能默认，不然并发起不来

问题

最近发现在k8s集群上，并发起来后接口返回耗时变长而且时不时还会重启。

原因

k8s上单个pod的系统配置为2C4G，而undertow的默认配置，请求连接数为cpu核数的8倍即16，加入16个请求都正在处理中，第17个请求就开始排队了。

解决方案

官方也是建议工作线程数的配置，取决于你机器的负载情况，其实也就是跟你的具体业务有关，我们现在的业务场景，16线程跑满的情况，CPU利用率仅仅百分之十几、CPU内存远远没利用完，再有请求过来，undertow则直接阻塞队列中，无法正常处理，资源浪费严重，还导致了服务中断的情况。

因此，从实际情况来看，一定不要采用undertow的官方默认配置。像我们线上业务来看，每个API接口业务耗时大多数在10ms以内，少部分耗时30-50ms时间，单接口耗用资源不大。 修改undertow配置 worker-threads=40，单节点可以承载40的并发任务，剩下的就是根据实际业务情况动态扩展节点数量即可。

io-threads：IO线程数, 它主要执行非阻塞的任务，它们会负责多个连接，默认设置每个CPU核心一个线程，不可设置过大，否则启动项目会报错：打开文件数过多。

worker-threads：阻塞任务线程池，当执行类似servlet请求阻塞IO操作，undertow会从这个线程池中取得线程。它的值取决于系统线程执行任务的阻塞系数，默认值是 io-threads*8，这里我们手动指定相应的值。

server:
  port: 1112
  undertow:
    io-threads: 8
    worker-threads: 256