使用Apache JMeter进行测试
Apache Jmeter是开源的压力测试工具，我们借助于此工具进行测试，将测试出tomcat 的吞吐量等信息。
下载安装
下载地址：http://jmeter.apache.org/download_jmeter.cgi
安装：直接将下载好的Zip压缩包进行解压即可。
进入bin目录，找到jmeter.bat文件，双击打开即可启动。
修改主题和语言
默认的主题是黑色风格的主题并且语言是英语，这样不太方便使用，所以需要修改下主题和中文语言。
接下来设置语言为简体中文。
语言修改完成。
创建首页的测试用例
第一步：保存测试用例
第二步：添加线程组，使用线程模拟用户的并发。
1000个线程，每个线程循环10次，也就是tomcat会接收到10000个请求。
第三步：添加http请求
第四步：添加请求监控
启动、进行测试
聚合报告
在聚合报告中，重点看吞吐量。
调整tomcat参数进行优化
通过上面测试可以看出，tomcat在不做任何调整时，吞吐量为73次/秒。
禁用AJP服务
可以看到，禁用AJP服务后，吞吐量会有所提升。
当然了，测试不一定准确，需要多测试几次才能看出是否有提升。
设置线程池
通过设置线程池，调整线程池相关的参数进行测试tomcat的性能。
最大线程数为500初始为50
<Executor name="tomcatThreadPool" namePrefix="catalina‐exec‐" maxThreads="500" minSpareThreads="50" prestartminSpareThreads="true"/>
测试结果：
最大线程数为1000，初始为200
<Executor name="tomcatThreadPool" namePrefix="catalina‐exec‐" maxThreads="1000" minSpareThreads="200" prestartminSpareThreads="true"/>
吞吐量为151，性能有所提升。
最大线程数为5000，初始为1000
是否是线程数越多，速度越快呢？我们来测试下。
<Executor name="tomcatThreadPool" namePrefix="catalina‐exec‐" maxThreads="5000" minSpareThreads="1000" prestartminSpareThreads="true"/>
可以看到，虽然最大线程已经设置到5000，但是实际测试效果并不理想，并且平均的响 应时间也边长了，所以单纯靠提升线程数量是不能一直得到性能提升的。
设置最大等待队列数
默认情况下，请求发送到tomcat，如果tomcat正忙，那么该请求会一直等待。这样虽然 可以保证每个请求都能请求到，但是请求时间就会边长。
有些时候，我们也不一定要求请求一定等待，可以设置最大等待队列大小，如果超过就 不等待了。这样虽然有些请求是失败的，但是请求时间会虽短。
典型的应用：12306。
<!‐‐最大等待数为100‐‐> <Executor name="tomcatThreadPool" namePrefix="catalina‐exec‐" maxThreads="500" minSpareThreads="100" prestartminSpareThreads="true" maxQueueSize="100"/>
测试结果：
平均响应时间：3.1秒
响应时间明显缩短
错误率：49.88%
错误率提升到一半，也可以理解，最大线程为500，测试的并发为1000
吞吐量：238次/秒
吞吐量明显提升
结论：响应时间、吞吐量这2个指标需要找到平衡才能达到更好的性能。
设置nio2的运行模式
将最大线程设置为500进行测试：
<Executor name="tomcatThreadPool" namePrefix="catalina‐exec‐" maxThreads="500" minSpareThreads="50" prestartminSpareThreads="true"/> <!‐‐ 设置nio2 ‐‐> <Connector executor="tomcatThreadPool" port="8080" protocol="org.apache.coyote.http11.Http11Nio2Protocol" connectionTimeout="20000" redirectPort="8443" />
可以看到，平均响应时间有缩短，吞吐量有提升，可以得出结论：nio2的性能要高于 nio。
调整JVM参数进行优化
接下来，测试通过jvm参数进行优化，为了测试一致性，依然将最大线程数设置为500， 启用nio2运行模式。
设置并行垃圾回收器
#年轻代、老年代均使用并行收集器，初始堆内存64M，最大堆内存512M JAVA_OPTS="‐XX:+UseParallelGC ‐XX:+UseParallelOldGC ‐Xms64m ‐Xmx512m ‐XX:+PrintGCDetails ‐XX:+PrintGCTimeStamps ‐XX:+PrintGCDateStamps ‐XX:+PrintHeapAtGC -Xloggc:../logs/gc.log"
测试结果与默认的JVM参数结果接近。（执行了2次测试，结果是第二次测试的结果）
查看GC日志文件
将gc.log文件上传到gceasy.io查看gc中是否存在问题。
问题一：
在报告中显示，在5次GC时，系统所消耗的时间大于用户时间，这反应出的服务器的性能 存在瓶颈，调度CPU等资源所消耗的时间要长一些。
问题二：
可以关键指标中可以看出，吞吐量表现不错，但是gc时，线程的暂停时间稍有点长。
问题三：
通过GC的统计可以看出：
年轻代的gc有74次，次数稍有多，说明年轻代设置的大小不合适需要调整
FullGC有8次，说明堆内存的大小不合适，需要调整
问题四：
从GC原因的可以看出，年轻代大小设置不合理，导致了多次GC。
调整年轻代大小
JAVA_OPTS="‐XX:+UseParallelGC ‐XX:+UseParallelOldGC ‐Xms128m ‐Xmx1024m ‐XX:NewSize=64m ‐XX:MaxNewSize=256m ‐XX:+PrintGCDetails ‐XX:+PrintGCTimeStamps ‐XX:+PrintGCDateStamps ‐XX:+PrintHeapAtGC ‐Xloggc:../logs/gc.log"
将初始堆大小设置为128m，最大为1024m
初始年轻代大小64m，年轻代最大256m
从测试结果来看，吞吐量以及响应时间均有所提升。
查看GC日志：
可以看到GC次数要明显减少，说明调整是有效的。
设置G1垃圾回收器
#设置了最大停顿时间100毫秒，初始堆内存128m，最大堆内存1024m
JAVA_OPTS="‐XX:+UseG1GC ‐XX:MaxGCPauseMillis=100 ‐Xms128m ‐Xmx1024m ‐XX:+PrintGCDetails ‐XX:+PrintGCTimeStamps ‐XX:+PrintGCDateStamps ‐XX:+PrintHeapAtGC ‐Xloggc:../logs/gc.log"
测试结果：
可以看到，吞吐量有所提升，评价响应时间也有所缩短。