使用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"
测试结果:
可以看到,吞吐量有所提升,评价响应时间也有所缩短。