Tomcat服务器-并发压力测试下调优注意点小结

 

1、Tomcat conf中server.xml有个重要的性能配置，根据机器的硬件性能合理的配置常驻线程数以及最大线程数，还有等待队列线程数：

    <Connector port="8081" protocol="HTTP/1.1"
               connectionTimeout="120000"
               redirectPort="8443"
               maxThreads="600"
               minSpareThreads="250"
               maxSpareThreads="250"
               acceptCount="400"
                uRIEncoding="utf-8"/>

关于maxThreads、acceptCount的意义请参见

http://www.cnblogs.com/baibaluo/archive/2011/08/23/2150305.html

这里只大概叙述如下：

这两个值如何起作用，请看下面三种情况

情况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限制。

 

这里以业务服务器为例，机器硬件好一点的话，4核2.5G的，maxThreads开到600-1000，是比较理想的。

如果想继续提高服务器的并发数，将acceptCount也设置为和maxThreads一样大。但是也需要合理的考虑单次的请求响应处理时间，一味的增加acceptCount只是避免了过多的超时拒绝，但是对于用户体验还是最好5秒之内一次响应能够处理完，这个时候增加后端的并行的Tomcat服务器将是明智的选择。

 

该图的就是在配置如下参数时，Tomcat线程池统计信息，在常态下维持250个线程，当应对高并发的情况下，系统不断地创建线程直到maxThreads设置的最大值为止。

               maxThreads="600"
               minSpareThreads="250"
               maxSpareThreads="250"
               acceptCount="400"

 

 

2、JVM虚拟机的启动配置 bin/catalina.sh

 

设定虚拟机的server启动方式，以及堆内存的初始分配大小，垃圾收集机制，线程最大堆栈配置数，新生代内存大小等等

 

a 、JVM Server模式与client模式启动，最主要的差别在于：-Server模式启动时，速度较慢，但是一旦运行起来后，性能将会有很大的提升。JVM如果不显式指定是-Server模式还是-client模式，JVM能够根据下列原则进行自动判断（适用于Java5版本或者Java以上版本）；

JVM client模式和Server模式的区别

 

b、线程堆栈 -Xss 1024K 可以根据业务服务器的每次请求的大小来进行分配；

 

c、－xms -xmx  是 jvm占用最小和最大物理内存配置参数，一般讲两者配置一样大，这样就免去了内存不够用时申请内存的耗时；

 

d、-XX:PermSize=128M -XX:MaxPermSize=128m

从前人的各类文章上了解到jvm的垃圾回收机制，这里只是简单提一下， jvm的内存分为2大类型，一个是perm型，另一个是generation型。perm区域存放的是class这些静态信息，一般默认64m，如果你的项目很大，有可能一启动就报错，out of memory permsize什么的，另外如果用spring框架的话很多类是动态反射加载的，运行一段时间有可能出现此异常，这种情况，设置下permsize就可以了。

另外一个类型才是重点，应用的代码基本上在这个区域活动，new的类都会在这个区域，而且jvm决大部分工作都在这里搞了，这个区详细说很复杂，有空去看sun资料，这里也只大概提下：这个区包含新生代和老生代区域，所有new出来的会放置在新区域，而多次回收失败的一些一直被使用的实例则被转移到老生代区域，所以新生代区域活动是最频繁的。新生代内存不足时会促发一次 这个区的gc －－－－然后再到老生代的gc－－－最后才轮到full gc。full gc代价很高，应该尽量避免，尽量在newsize参数的这个区gc，一般配置 newsize分配到总内存1／4左右，－－－最终，如果full gc 还是内存不足，那就会引发out of memory 常见的那种。

-----------摘自jvm 参数优化－－－笔记

 

e、-XX:+UseParallelGC -XX:ParallelGCThreads=2 -XX:+UseAdaptiveSizePolicy
这几个参数，一般的应用没什么必要，UseParallelGC 并行回收，XX:ParallelGCThreads 并行回收线程数，只有配置了UseParallelGC有效。UseAdaptiveSizePolicy，让jvm根据情况动态适配参数，当然如果你指定了某些参数，jvm就不会对那些参数再去调整的，加这个参数只要是让我们考虑不全的其它参数能让jvm帮忙做微处理。 总之UseParallelGC目的是 加快jvm回收频率 。

关于垃圾回收更详细的文章请见:

tomcat查看GC信息

 

下图只是简单的配置了:

JAVA_OPTS="-server -Xms1536m -Xmx1536m -Xss1024K -XX:PermSize=128m -XX:MaxPermSize=256m"

 

Tomcat堆内存的垃圾回收情况，可以看到默认是当系统使用到了阀值后进行GC回收

 

 

转自：http://blog.csdn.net/shuzui1985/article/details/8577233