Tomcat 7优化前及优化后的性能对比

参考：https://my.oschina.net/lianss/blog/272230

           http://www.cnblogs.com/dsc65749924/p/6081432.html

 

摘要: Tomcat 7在我们日常开发、测试、生产环境都会使用到，但对于大部分开发人员来说，对其性能还是没有多大了解。本文就对它做一次性能测试，对比优化前后的性能区别。

 

一、运行环境

CPU： Intel(R) Pentium(R) P6200@2.13GHz  ；

内存：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