由于Web应用程序跑在Tomcat工作线程,因此Web应用对请求的处理时间也直接影响Tomcat性能,而Tomcat和Web应用在运行过程中所用到的资源都来自os,因此调优需要将服务端看作是一个整体来考虑。
I/O调优实际上是连接器类型的选择,一般情况下默认都是NIO,在绝大多数情况下都是够用的。
除非你的Web应用用到了TLS加密传输,而且对性能要求极高,这个时候可以考虑APR,因为APR通过OpenSSL来处理TLS握手和加/解密。OpenSSL本身用C语言实现,它还对TLS通信做了优化,所以性能比Java高。
若你的Tomcat跑在Windows,且HTTP请求的数据量较大,可考虑NIO.2。因为Windows从os实现了真正的异步I/O,若传输数据量较大,异步I/O效果就能显露出来。
若Tomcat在Linux,建议NIO,Linux内核没有完善支持异步I/O,因此JVM也没有采用原生的Linux异步I/O,而是在应用层面通过epoll模拟异步I/O模型,只是Java NIO的使用者感觉不到。 因此在Linux,Java NIO和Java NIO.2底层其实都是通过epoll实现,但Java NIO更简单高效。
跟I/O模型紧密相关的是线程池,线程池的调优就是设置合理的线程池参数。
如何确定maxThreads:
maxThreads多少合适呢?
系统中的请求数 = 请求的到达速率 × 每个请求处理时间
去超市结账排队,如何估算一个队列有多长呢?
因此队列的长度等于 新人加入队列的频率 乘以 平均每个人处理的时间。
计算出了队列的长度,就创建相应数量线程处理请求,这样既能以最快速度处理完所有请求,同时又没有额外的线程资源闲置和浪费。
假设一个单核服务器在接收请求:
因此可以总结出一个公式:
线程池大小 = 每秒请求数 × 平均请求处理时间
理想情况,线程一直在忙着干活,没有被阻塞在I/O等待。
实际上任务在执行中,线程不可避免会发生阻塞,比如阻塞在I/O等待上,等待DB或下游服务响应,虽然通过非阻塞I/O模型可减少线程的等待,但是数据在用户空间和内核空间拷贝过程中,线程还是阻塞。 线程一阻塞就会让出CPU,线程闲置下来,就好像工作人员不可能24h处理请求,解决办法就是增加工作人员数量,一个人去休息另一个人顶上。即增加线程数,因此I/O密集型应用需要设置更多的线程。
至此我们又得到一个线程池个数的计算公式,假设服务器是单核:
线程池大小 = (线程I/O阻塞时间 + 线程CPU时间 )/ 线程CPU时间
线程I/O阻塞时间 + 线程CPU时间 = 平均请求处理时间
平均请求处理时间在两公式都有,这说明请求时间越长,必然需要更多的线程。
不同的是:
虽然这两个公式是从不同的角度来看待问题的,但都是理想情况,有前提条件:
先用上面两公式估算出理想线程数,再压测调整,达到最优。
一般若系统TPS要求足够大,用第一个公式算出来的线程数往往会比公式二算出来的要大。我建议选取这两个值中间更靠近公式二的值。 即先设置一个较小的线程数,然后进行压测,当达到系统极限时(错误数增加,或者响应时间大幅增加),再逐步加大线程数,当增加到某个值,再增加线程数也无济于事,甚至TPS反而下降,那这个值可以认为是最佳线程数。
线程池中其他参数,最好就默认值,能不改就不改,除非在压测的过程发现瓶颈。 如果发现了问题就需要调整,比如maxQueueSize,如果大量任务来不及处理都堆积在maxQueueSize中,会导致内存耗尽,这个时候就需要给maxQueueSize设一个限制。当然,这是一个比较极端的情况了。
再比如minSpareThreads参数,默认25个线程,如果发现系统在闲的时候用不到25个线程,就可以调小一点;如果系统在大部分时间都比较忙,线程池中的线程总是远远多于25个,这个时候你就可以把这个参数调大一点,这样线程池就不需反复创建和销毁线程。
假如有个状况:系统响应比较慢,但CPU的用率不高,内存有所增加,通过分析Heap Dump发现大量请求堆积在线程池的队列中,请问这种情况下应该怎么办呢?
应该怀疑大量线程被阻塞了,应该看看web应用是不是在访问外部数据库或者外部服务遇到了延迟。