Tomcat 7优化前及优化后的性能对比
参考：https://my.oschina.net/lianss/blog/272230
http://www.cnblogs.com/dsc65749924/p/6081432.html
摘要: Tomcat 7在我们日常开发、测试、生产环境都会使用到，但对于大部分开发人员来说，对其性能还是没有多大了解。本文就对它做一次性能测试，对比优化前后的性能区别。
一、运行环境
CPU： Intel(R) Pentium(R) [email protected] ；
内存：4G，装的是32位win7
操作系统：win7 32位；
JDK：1.7.0_55
Tomcat：7.0.53
下面所有测试都是基于1000个请求做的，且都是访问Tomcat默认的ROOT首页
二、未调优前
并发用户数从10-1000挨个测试，测试结果如下：
从上面的测试结果来看，除去200用户并发的时候（这时候可能在做GC），吞吐率和请求处理时间都比较稳定，但请求等待时间到后面就飕飕的往上涨了。经观察，CPU负载均在80%以下。
三、优化后
优化主要是对Tomcat做的，主要有两方面：
1、在bin/catalina.bat文件中加入下面参数，对JVM进行优化，至于这一大驼参数的作用及说明，大家到网上找找，应该有很多的，如：http://www.mzone.cc/article/321.html
----------------------
set JAVA_OPTS=
-server
-Xms1000M
-Xmx1000M #-Xms与-Xmx设成一样的值，避免JVM因为频繁的GC导致性能大起大落
-Xss512k
-XX:+AggressiveOpts
-XX:+UseBiasedLocking
-XX:PermSize=64M
-XX:MaxPermSize=300M
-XX:+DisableExplicitGC
-XX:MaxTenuringThreshold=31
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled
-XX:+UseCMSCompactAtFullCollection
-XX:LargePageSizeInBytes=128m
-XX:+UseF
----------------------
/**
参数说明：
-server 指定JAVA虚拟机运行在server模式
-Xms 初始Heap内存大小，本文档设置了3G，需要结合服务器CPU核数，内存总量等实际情况来设置合适数值，此值并非越大越好，过大将增加垃圾回收的压力
-Xmx 最大Heap内存大小，本文档设置了3G，需要结合服务器CPU核数，内存总量等实际情况来设置合适数值，此值并非越大越好，过大将增加垃圾回收的压力
-Xmn 新生代内存大小
-Xss 每个线程的堆栈大小
-XX:+AggressiveOpts 启用JVM开发团队最新的调优成果，例如：编译优化，偏向锁，并行老年代收集，JDK5.6后引入，JDK6默认开启
-XX:+UseBiasedLocking 启用一个优化了的线程锁（偏向锁），JDK5.6后引入，JDK6默认开启
-XX:PermSize 初始持久代内存大小，需要注意永久代在JDK8中被完全的移除了，永久代的参数-XX:PermSize和-XX:MaxPermSize也被移除了
-XX:MaxPermSize 最大持久代内存大小，需要注意永久代在JDK8中被完全的移除了，永久代的参数-XX:PermSize和-XX:MaxPermSize也被移除了
-XX:+DisableExplicitGC 禁止显示的调用System.gc()方法进行GC
-XX:+UseConcMarkSweepGC 使用并发标记清除（CMS）垃圾收集器 它是对年老代进行垃圾收集的。CMS收集器通过多线程并发进行垃圾回收，尽量减少垃圾收集造成的停顿。采用这种垃圾收集器默认会开启-XX:+UseParNewGC参数对新生代使用Parallel GC(并行垃圾回收器)
-XX:+UseParNewGC 新生代使用Parallel GC(并行垃圾回收器)，如果老年代使用了CMS垃圾回收期，则新生代默认就是这种垃圾回收器
-XX:+CMSParallelRemarkEnabled CMS垃圾回收器回收对象时，应用有2次停顿，第一次是初始标记，第二次是重新标记，开启并行remark可以降低重新标记停顿时间，
-XX:+UseCMSCompactAtFullCollection CMS不会整理堆碎片，为了防止堆碎片引起full gc，设置此参数使CMS垃圾回收时进行合并碎片，开启这个选项一定程度上会影响性能
-XX:CMSMaxAbortablePrecleanTime
-XX:+CMSClassUnloadingEnabled 开启CMS回收持久代，避免Perm区满引起的full gc
-XX:LargePageSizeInBytes 指定Java heap的分页页面大小
-XX:+UseFastAccessorMethods 将get(),set()方法转成本地代码，默认开启
-XX:+UseCMSInitiatingOccupancyOnly 只有达到-XX:CMSInitiatingOccupancyFraction指定的使用百分比才进行老年代的垃圾回收
-XX:CMSInitiatingOccupancyFraction 指定老年代在使用了多少百分比空间时开始进行垃圾回收，JDK5默认68%，JDK6默认92%
-Djava.awt.headless 解决J2EE工程中的图表工具在Linux/Unix环境下会导致图片显示不出来
-Xloggc 指定JVM日志输出到文件
-XX:+PrintGCDateStamps 打印GC发生的时间，JDK6和JDK7才支持，如果是JDK5请使用-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationStoppedTime 打印GC造成应用停顿的时间
-XX:+PrintGCApplicationConcurrentTime 打印GC时应用并发执行的时间
-XX:+PrintGCDetails 打印GC详细信息
*/
上述这样的配置，基本上可以达到：
-系统响应时间增快
-JVM回收速度增快同时又不影响系统的响应率
-JVM内存最大化利用
-线程阻塞情况最小化
2、Tomcat连接参数的优化，主要是针对吞吐量做优化：
修改conf/server.xml文件，把原来
<Connector port="8080" protocol="HTTP/1.1" />
改成下面的内容
----------------------
<Connector port="8080" protocol="HTTP/1.1"
URIEncoding="UTF-8"
minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false"
disableUploadTimeout="true"
connectionTimeout="20000"
acceptCount="300"
maxThreads="300"
maxProcessors="1000"
minProcessors="5"
useURIValidationHack="false"
compression="on"
compressionMinSize="2048"
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"
redirectPort="8443"/>
----------------------
/**
参数说明：
executor="tomcatThreadPool" 在 Connector里指定使用共享线程池的名称
port="8080" 指定服务器端要创建的端口号，并在这个端口监听来自客户端的请求
protocol="HTTP/1.1" 负责建立HTTP连接，web应用通过浏览器访问tomcat服务器用的就是这个连接器，默认监听的是8080端口。所以我们优化的是8080端口的Connector
URIEncoding="UTF-8" URI解码所使用的字符集，只影响GET请求的URI解码，不影响post的解码
enableLookups="false" 禁用DNS查询，默认值为true，为了提高处理能力应设置为false
disableUploadTimeout="true" 允许servlet container在一个servlet执行的时候，使用一个不同的，更长的连接超时。最终的结果是给servlet更长的时间以便完成其执行，或者在数据上载的时候更长的超时时间。如果没有指定默认为false
connectionTimeout="20000" 在Connector接受一个连接以后，等待发生第一个请求的时间，单位毫秒。缺省值为60000（60秒）
keepAliveTimeout="15000" 在一个长连接中2次请求之间的最大间隔时间，超过此时间连接断开，单位毫秒
maxKeepAliveRequests="1000" 在server关闭连接之前，接受的HTTP请求的最大数目。如果该值设为1，会禁止HTTP/1.0保活，同时也会禁止HTTP/1.1保活和pipelining。如果没有指定默认值100。
useURIValidationHack="false" 减少它对一些url的不必要的检查从而减省开销
compression="on" 设为on开启Connector使用HTTP/1.1的GZIP压缩,可节省服务器带宽
compressionMinSize="2048" 启用压缩的输出内容大小,这里面设置为2KB
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" 压缩文件的类型
redirectPort="8443" 如果Connector支持非SSL请求，在收到一个要求使用SSL传输的请求以后，Catalina会自动将该请求重定向到这里指定的端口号
*/
然后我们再来看看10-1000个并发用户发起1000个请求时所表现的性能是怎么的。
大家可以看到，经过优化后，吞吐率已经能达到平均1800-1900左右，而处理时间基本能稳定在0.6ms，而等待时间最高不到600ms
四、总结
通过两个结果对比可以看出，吞吐率及服务器处理时间有很大的改观。
另外文章：http://phl.iteye.com/blog/1982676