Tomcat 7 在我们日常开发、测试、生产环境都会使用到，但对于大部分开发人员来说，对其性能还是没有多大了解。本文就对它做一次性能测试，对比优化前后的性能区别。
一、运行环境
CPU ： Intel(R) Pentium(R) P6200@2.13GHz ；
内存： 4G ，装的是 32 位 win7 ，只认出 3G ，没有花时间去整 ramdisk 之类的东西；
操作系统： 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
|
01 |
set JAVA_OPTS= |
|
|
02 |
-server |
|
|
03 |
-Xms1000M |
|
|
04 |
-Xmx1000M #-Xms与-Xmx设成一样的值，避免JVM因为频繁的GC导致性能大起大落 |
|
|
05 |
-Xss512k |
|
|
06 |
-XX:+AggressiveOpts |
|
|
07 |
-XX:+UseBiasedLocking |
|
|
08 |
-XX:PermSize=64M |
|
|
09 |
-XX:MaxPermSize=300M |
|
|
10 |
-XX:+DisableExplicitGC |
|
|
11 |
-XX:MaxTenuringThreshold=31 |
|
|
12 |
-XX:+UseConcMarkSweepGC |
|
|
13 |
-XX:+UseParNewGC |
|
|
14 |
-XX:+CMSParallelRemarkEnabled |
|
|
15 |
-XX:+UseCMSCompactAtFullCollection |
|
|
16 |
-XX:LargePageSizeInBytes=128m |
|
|
17 |
-XX:+UseFastAccessorMethods |
|
|
18 |
-XX:+UseCMSInitiatingOccupancyOnly |
|
|
19 |
-Djava.awt.headless=true |
上述这样的配置，基本上可以达到：
- 系统响应时间增快
- JVM回收速度增快同时又不影响系统的响应率
- JVM内存最大化利用
- 线程阻塞情况最小化
2 、 Tomcat 连接参数的优化，主要是针对吞吐量做优化：
修改 conf/server.xml 文件，把原来
|
1 |
<Connector port="8080" protocol="HTTP/1.1" /> |
改成下面的内容
|
01 |
<Connector port="8080" protocol="HTTP/1.1" |
|
|
02 |
URIEncoding="UTF-8" |
|
|
03 |
minSpareThreads="25" |
|
|
04 |
maxSpareThreads="75" |
|
|
05 |
enableLookups="false" |
|
|
06 |
disableUploadTimeout="true" |
|
|
07 |
connectionTimeout="20000" |
|
|
08 |
acceptCount="300" |
|
|
09 |
maxThreads="300" |
|
|
10 |
maxProcessors="1000" |
|
|
11 |
minProcessors="5" |
|
|
12 |
useURIValidationHack="false" |
|
|
13 |
compression="on" |
|
|
14 |
compressionMinSize="2048" |
|
|
15 |
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" |
||
|
16 |
redirectPort="8443"/> |
||
然后我们再来看看
10-1000
个并发用户发起
1000
个请求时所表现的性能是怎么的。
大家可以看到，经过优化后，吞吐率已经能达到平均 1800-1900 左右，而处理时间基本能稳定在 0.6ms ，而等待时间最高不到 600ms 。
四、总结
通过两个结果对比可以看出，吞吐率及服务器处理时间有很大的改观，当然在我这破机器上也就这样一个效果了，再优化估计也不会 “ 飞 ” 起来，有兴趣的朋友可以找台牛 B 点的机器自己试试。试完了希望告诉我结果，让我也高兴一下。
