Tomcat容器并发性能涉及概念及配置

Tomcat线程池并发调优

版本：tomcat7

官方文档：Apache Tomcat 7 Configuration

tomcat性能优化主要从启动参数和server入手，server则主要是从excutor和connector着手，网上文章一大堆，鱼龙混杂，大部分文章自己都解释不清。最好的办法是去看官方文档。

对于大型应用，如果用tomcat的话，应该考虑在参数优化后进行压测，找到单机能承受的最大压力，然后考虑横向扩展应用集群。

下面对参数调优中的几项关键参数做说明（参照官方文档）。

---

server.xml

excutor

• maxThreads

  线程池里面的最大活跃线程数

• maxQueueSize

  (int) The maximum number of runnable tasks that can queue up awaiting execution before we reject them. Default value is Integer.MAX_VALUE

  在被服务器拒绝之前能够排队等待运行的最大任务数。默认是Integer.MAX_VALUE

  这个参数既然默认值都是最大值了，那么非必要情况不用配置这个参数。

• minSpareThreads

  (int) The minimum number of threads (idle and active) always kept alive, default is 25

  最小空闲线程数，默认25个。结合maxIdleTime，可以理解为至少存在25个空闲线程随时待命。

• maxIdleTime

  (int) The number of milliseconds before an idle thread shutsdown, unless the number of active threads are less or equal to minSpareThreads. Default value is 60000(1 minute)

  理解为空闲线程的最大存活时间（默认一分钟），一个进程空闲时间超过这个时间后，会被关闭。除非当前线程池里面的线程数已经小于等于minSpareThreads。

Connector

针对较为复杂且流程处理耗时较大的系统，首先把protocol换成nio。

org.apache.coyote.http11.Http11NioProtocol - non blocking Java connector

BIO、NIO、APR三者特点如下：

BIO更适合处理简单流程，如程序处理较快可以立即返回结果。

NIO更适合后台需要耗时完成请求的操作，如程序接到了请求后需要比较耗时的处理这已请求，所以无法立即返回结果，这样如果采用BIO就会占用一个连接，而使用NIO后就可以将此连接转让给其他请求，直至程序处理完成返回为止。

APR可以大大提升Tomcat对静态文件的处理性能，同时如果你使用了HTTPS方式传输的话，也可以提升SSL的处理性能。

• maxThreads

  The maximum number of request processing threads to be created by this Connector, which therefore determines the maximum number of simultaneous requests that can be handled. If not specified, this attribute is set to 200. If an executor is associated with this connector, this attribute is ignored as the connector will execute tasks using the executor rather than an internal thread pool. Note that if an executor is configured any value set for this attribute will be recorded correctly but it will be reported (e.g. via JMX) as -1 to make clear that it is not used.

  线程池的最大线程数，表示tomcat最多能起这么多个线程

• maxConnections

  The maximum number of connections that the server will accept and process at any given time. When this number has been reached, the server will accept, but not process, one further connection. This additional connection be blocked until the number of connections being processed falls below maxConnections at which point the server will start accepting and processing new connections again. Note that once the limit has been reached, the operating system may still accept connections based on the acceptCount setting. The default value varies by connector type. For BIO the default is the value of maxThreads unless an Executor is used in which case the default will be the value of maxThreads from the executor. For NIO the default is 10000. For APR/native, the default is 8192.

  If set to a value of -1, the maxConnections feature is disabled and connections are not counted.

  最大连接数，相当于给定时间段内服务器能接受并运行的并发请求数。当并发请求达到这个数值后，服务器会继续接受请求但不运行（放到acceptCount队列，这个队列满后就不再接受请求）。

• minSpareThreads

  The minimum number of threads always kept running. This includes both active and idle threads. If not specified, the default of 10 is used. If an executor is associated with this connector, this attribute is ignored as the connector will execute tasks using the executor rather than an internal thread pool. Note that if an executor is configured any value set for this attribute will be recorded correctly but it will be reported (e.g. via JMX) as -1 to make clear that it is not used.

• acceptCount

  The maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 100.

  等待队列的size，默认值100。当线程池里边的可用线程全部被使用时，再有请求尽量就会排队到这个队列，直到又有可用线程能够消费。当这个队列也满了后，如果还有请求进来就会被拒绝（connection refused等）。

• acceptorThreadCount

  The number of threads to be used to accept connections. Increase this value on a multi CPU machine, although you would never really need more than 2. Also, with a lot of non keep alive connections, you might want to increase this value as well. Default value is 1.

  用于接收连接的线程数。对于多核CPU，可以增加这个值，非keep-alive的连接也可以增加这个值。默认为1.可以设置为cpu的线程数。

---

对并发性能影响最关键的连个参数：maxThreads and acceptCount:

maxThreads是指Tomcat线程池做多能起的线程数
maxConnections则是Tomcat一瞬间做多能够处理的并发连接数。比如maxThreads=1000，maxConnections=800，假设某一瞬间的并发时1000，那么最终Tomcat的线程数将会是800，即同时处理800个请求，剩余200进入队列“排队”，如果acceptCount=100，那么有100个请求会被拒掉。

注意：根据前面所说，只是并发那一瞬间Tomcat会起800个线程处理请求，但是稳定后，某一瞬间可能只有很少的线程处于RUNNABLE状态，大部分线程是TIMED_WAITING，如果你的应用处理时间够快的话。所以真正决定Tomcat最大可能达到的线程数是maxConnections这个参数和并发数，当并发数超过这个参数则请求会排队，这时响应的快慢就看你的程序性能了。

JVM菜鸟进阶高手之路七（tomcat调优以及tomcat7、8性能对比）

情况1：接受一个请求，此时tomcat起动的线程数没有到达maxThreads，tomcat会起动一个线程来处理此请求。

情况2：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，tomcat会把此请求放入等待队列，等待空闲线程。

情况3：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，等待队列中的请求个数也达到了acceptCount，此时tomcat会直接拒绝此次请求，返回connection refused

一般的服务器操作都包括量方面：1计算（主要消耗cpu），2等待（io、数据库等）

第一种极端情况，如果我们的操作是纯粹的计算，那么系统响应时间的主要限制就是cpu的运算能力，此时maxThreads应该尽量设的小，降低同一时间内争抢cpu的线程个数，可以提高计算效率，提高系统的整体处理能力。

第二种极端情况，如果我们的操作纯粹是IO或者数据库，那么响应时间的主要限制就变为等待外部资源，此时maxThreads应该尽量设的大，这样才能提高同时处理请求的个数，从而提高系统整体的处理能力。此情况下因为tomcat同时处理的请求量会比较大，所以需要关注一下tomcat的虚拟机内存设置和linux的open file限制。

TOMCAT优化，提高并发能力

具体配置

性能测试

测试工具：Jmeter、jvisualvm.exe

在jmeter 500线程模拟访问的时候，用jvisualvm观察线程情况和GC情况，控制jmeter 500模拟线程不变，分别测试不同组tomcat server有关线程的配置参数。通过观察对于单个tomcat，过高的线程数会导致cpu性能过多的消耗在频繁的上下文切换和创建及回收线程资源上。过低的线程数则不能承受并发，产生大量的连接失败的情况。根据多次压测结果、GC分析和线程分析推测，单机tomcat并发数应控制在800左右比较合理。

配置参数：

<Executor name="tomcatThreadPool" 
		  namePrefix="catalina-exec-" 
		  prestartminSpareThreads="true" 
		  maxThreads="500" 
		  minSpareThreads="50"
		  maxIdleTime="10000" />

<Connector executor="tomcatThreadPool"
		   port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
           connectionTimeout="20000"
           acceptCount="400"
           acceptorThreadCount="4"
           maxConnections="800"
           compression="on"
           enableLookups="false"
           redirectPort="8443" />