• Tomcat8优化--调整tomcat参数和JVM参数进行优化


    调整tomcat参数学进行优化

    禁用AJP

     查看报告

    可以看到,禁用AJP服务后,吞吐量有所提升;

    当然了,测试不一定准确,需要多册测试才能看出是否有所提升;

    设置线程池

    通过设置线程池,调整线程池相关的参数进行测试tomcat的性能

    最大线程数为500,初始为50

    <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="500" minSpareThreads="50" prestartminSpareThreads="true"/>
    

    测试结果:

     吞吐量为128次/秒,性能有所提升;

    最大线程数为1000,初始为200

    <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="1000" minSpareThreads="200" prestartminSpareThreads="true"/>
    

    测试结果:

     最大线程数为5000,初始为1000

    <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="5000" minSpareThreads="1000" prestartminSpareThreads="true"/>
    

    测试结果:

    可以看到,虽然最大线程已经设置到5000,但是实际测试效果并不理想,并且平均的响应时间也长了,所以单纯靠提升线程数量是不能一直得到性能提升的;

    设置最大等待队列数

    默认情况下,请求发送到tomcat,如果tomcat正忙,那么该请求会一直等待。这样虽然可以保证每个请求都能请求到,但是请求时间就会变长;

    有些时候,我们也不一定要求请求一定等待,可以设置最大等待队列大小,如果超过就不等待了。这样虽然有些请求时失败的,但是请求时间会变短。

    <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="500" minSpareThreads="100" 
    prestartminSpareThreads="true" axQueueSize="100"/>

    测试结果:

    结论:响应时间,吞吐量这2个指标需要找到平衡才能达到更好的性能;

    设置nio2的运行模式

    将最大线程设置为500进行测试:

    <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="500" minSpareThreads="50" 
    prestartminSpareThreads="true" axQueueSize="100"/>

    设置nio2:

    <Connector executor="tomcatThreadPool"
                   port="8080" protocol="org.apache.coyote.http11.Http11Nio2Protocol"
                   connectionTimeout="20000"
                   redirectPort="8443" />
    

    测试结果:

     可以看到,平均响应时间有缩短,吞吐量有提升,可以得到结论:nio2的性能要高于nio;

    JVM参数进行优化

    下面,测试通过JVM参数进行优化,为了测试一致性,依然将最大线程数设置为500,启用nio2运行模式;

    设置并行垃圾收集器

    JAVA_OPTS="-XX:+UseParallelGC -XX:+UseParallelOldGC -Xms64m -Xmx512m -XX:+PrintGCDetails 
    -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:../logs/gc.log"

    测试结果:

    查看ge日志文件

    将gc.log文件上传到gceasy.io查看gc中是否存在问题

    问题一:

    可以关键指标中可以看出,吞吐量表现不错,但是GC时,线程的暂停时间有点长;

    问题二:

    通过GC的统计可以看出:

      年轻代的GC有68次,次数有点多,说明年轻代设置的大小不合适需要调整;

      Full GC有8次,说明堆内存的大小不适合,需要调整;

    问题三:

     从GC原因可以看出,年轻代大小设置不合理,导致了多次GC;

    调整年轻代大小

    JAVA_OPTS="-XX:+UseParallelGC -XX:+UseParallelOldGC -Xms128m -Xmx1024m -XX:+PrintGCDetails 
    -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:../logs/gc.log"

    通过调整年轻代大小,可以减少GC次数;

    设置GI垃圾收集器

    JAVA_OPTS="-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -Xms128m -Xmx1024m -XX:+PrintGCDetails 
    -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:../logs/gc.log"

    小结

    通过上述的测试,可以总结出,对tomcat性能优化就是需要不断的进行调整参数,然后测试结果,可能会调优也可能会调差,这是就需要借助于gc的可视化工具来查看gc的情况;  

      

     

      

      

      

      

      

  • 相关阅读:
    进程与线程
    silverlight中的几个冷门标记 {x:Null},d:DesignWidth,d:DesignHeight
    silverlight数据绑定模式TwoWay,OneWay,OneTime的研究
    silverlight 相册雏型
    IIS7的应用程序池
    silverlight如何在运行时用代码动态控制(或创建)动画
    庆祝silverlight 4 beta版发布,上几张养眼MM照片
    [转贴]Silverlight Socket 实现收发信息
    IIS7.5中神秘的ApplicationPoolIdentity
    silverlight中如何将string(字符串)写入Resource(资源)?
  • 原文地址:https://www.cnblogs.com/dabrk/p/12464280.html
Copyright © 2020-2023  润新知