总结tomcat优化方法

##1、概述
Tomcat的运行依赖于JVM，从虚拟机的角度把Tomcat的调整分为外部环境调优 和 Tomcat 自身调优两部分

##2、外部环境JVM调优
Tomcat首先跑在JVM之上的，因为它的启动其实也只是一个java命令行，首先我们需要对这个JAVA的启动命令行进行调优。

帮助：man java
选项分类
-选项名称 此为标准选项,所有HotSpot都支持
-X选项名称 此为稳定的非标准选项
-XX:选项名称 非标准的不稳定选项，下一个版本可能会取消

#查看java命令标准选项
[root@centos ~]#java
#查看java的非标准选项
[root@centos8 ~]#java -X
#查看所有不稳定选项的当前生效值
[root@centos8 ~]#java -XX:+PrintFlagsFinal
#查看所有不稳定选项的默认值
[root@centos8 ~]#java -XX:+PrintFlagsInitial
#查看当前命令行的使用的选项设置
[root@centos8 ~]#java -XX:+PrintCommandLineFlags

实例：
[root@centos8 ~]#vim /usr/local/tomcat/bin/catalina.sh
JAVA_OPTS="-server -Xms4g -Xmx4g -Xss512k -Xmn1g -XX:CMSInitiatingOccupancyFraction=65 -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=10 -XX:NewRatio=2 -XX:PermSize=128m -XX:MaxPermSize=512m -XX:CMSFullGCsBeforeCompaction=5 -XX:+ExplicitGCInvokesConcurrent -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods"

-server：服务器模式
tomcat默认是以一种叫java –client的模式来运行的，server即意味着你的tomcat是以真实的production的模式在运行的，这也就意味着你的tomcat以 server模式运行时将拥有：更大、更高的并发处理能力，更快更强捷的JVM垃圾回收机制，可以获得更多的负载与吞吐量等。这个参数必须加上。

-Xms：设置应用程序初始使用的堆内存大小（年轻代+老年代) 4g
-Xmx：设置应用程序能获得的最大堆内存4g
调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。对于SUN和HP等虚拟机，推荐将最小堆大小和最大堆大小设置为同一值，因为这样可以避免浪费用于时常调整堆大小所需的 VM 资源。客户系统如果用到IBM虚拟机，要特别的注意设置-Xms和-Xmx一样大小会耽误垃圾回收的开始直到堆满，这样第一次垃圾回收就会变成非常昂贵的操作。推荐把-Xms设置为应用所需的最小值，这样会产生高效的垃圾回收。
#一台tomcat服务器并发连接数不高,生产建议分配物理内存通常4G到8G较多,如果需要更多连接,一般会利用虚拟化技术实现多台tomcat

-Xss：设定每个线程的堆栈大小512k
依据你的程序，看一个线程 大约需要占用多少内存，可能会有多少线程同时运行等。一般不易设置超过1M，要不然容易出现out ofmemory。

-Xmn：同时设置-XX:NewSize 和 -XX:MaxNewSize，代替两者。年轻代大小1g

-XX:CMSInitiatingOccupancyFraction=65
CMSInitiatingOccupancyFraction，这个参数设置有很大技巧，基本上满足(Xmx-Xmn)(100- CMSInitiatingOccupancyFraction)/100>=Xmn就 不会出现promotion failed。在我的应用中Xmx是4g，Xmn是1g，那么Xmx-Xmn是3096兆，也就是年老代有3096兆，CMSInitiatingOccupancyFraction=90说明年老代到65%满的时候开始执行对年老代的并发垃圾回收（CMS），这时还 剩35%的空间是3096*35%=1083.6兆，所以即使Xmn（也就是年轻代共1024兆）里所有对象都搬到年老代里，1083.6兆的空间也足够了，所以只要满 足上面的公式，就不会出现垃圾回收时的promotion failed；
因此这个参数的设置必须与Xmn关联在一起。

-XX:+AggressiveOpts
作用如其名（aggressive），启用这个参数，则每当JDK版本升级时，你的JVM都会使用最新加入的优化技术（如果有的话）

-XX:+UseBiasedLocking
启用一个优化了的线程锁，我们知道在我们的appserver，每个http请求就是一个线程，有的请求短有的请求长，就会有请求排队的现象，甚至还会出现线程阻塞，这个优化了的线程锁使得你的appserver内对线程处理自动进行最优调配。

-XX:+DisableExplicitGC
禁用Full gc显示调用“System.gc()”

-XX:MaxTenuringThreshold=10
设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一 个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概率。
这个值的设置是根据本地的jprofiler监控后得到的一个理想的值，不能一概而论原搬照抄。

-XX:NewRatio=2：以比例方式设置新生代和老年代new/old=1/2

-XX:PermSize=128m
-XX:MaxPermSize=512m
JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；
在数据量的很大的文件导出时，一定要把这两个值设置上，否则会出现内存溢出的错误。
-XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。那么，如果是物理内存4GB，那么64分之一就是64MB，这就是PermSize默认值，也就是永生代内存初始大小；四分之一是1024MB，这就是MaxPermSize默认大小。

-XX:CMSFullGCsBeforeCompaction=5
设置在执行多少次Full GC后对内存空间进行压缩整理
因为内存压缩整理的过程是没法并发执行的，所以难免要停顿，要尽量的减少这个停顿时间。根据具体情况，如果Full GC比较频繁，只调优这个参数的情况下，那么就不能每次都整理内存空间，不然积少成多，停顿的时间也是很可观的，此时就要调大该参数，让CMS在经过多次Full GC后再对内存空间进行压缩整理。

-XX:+ExplicitGCInvokesConcurrent
命令JVM无论什么时候调用系统GC,都执行CMS GC,而不是Full GC。

-XX:+UseConcMarkSweepGC
即CMS gc，这一特性只有jdk1.5即后续版本才具有的功能，它使用的是gc估算触发和heap占用触发。
我们知道频频繁的GC会造面JVM的大起大落从而影响到系统的效率，因此使用了CMS GC后可以在GC次数增多的情况下，每次GC的响应时间却很短，比如说使用了CMS GC后经过jprofiler的观察，GC被触发次数非常多，而每次GC耗时仅为几毫秒。

-XX:+UseParNewGC
对年轻代采用多线程并行回收，这样收得快。

-XX:+CMSParallelRemarkEnabled
在使用UseParNewGC 的情况下, 尽量减少 mark 的时间

-XX:+UseCMSCompactAtFullCollection
在使用concurrent gc 的情况下, 防止 memoryfragmention, 对live object 进行整理, 使 memory 碎片减少。

-XX:LargePageSizeInBytes=128m
指定 Java heap的分页页面大小

-XX:+UseFastAccessorMethods
get,set 方法转成本地代码

##2.1、Tomcat与其它web服务器整合使用
虽然tomcat也可以作web服务器,但其处理静态html的速度比不上apache,且其作为web服务器的功能远不如apache,因此我们想把 apache和tomcat集成起来，将html与jsp的功能部分进行明确分工，让tomcat只处理jsp部分，其它的由apache,IIS等这些 web服务器处理，由此大大节省了tomcat有限的工作线程 。

##2.2、负载均衡
在负载均衡的思路下，多台服务器为对等方式，每台服务器都具有同等的地位，可以单独对外提供服务而无须其他服务器的辅助。通过负载分担技术，将外部发送来的请求按一定规则分配到对称结构中的某一台服务器上，而接收到请求的服务器都独立回应客户机的请求。

提供服务的一组服务器组成了一个应用服务器集群(cluster)，集群下的对等多机环境可以增加系统的并发处理能力，和单台机器出现故障系统的错误冗余能力；同时实现了负载均衡和系统高可靠性。

四种实现负载均衡的方式：

第一是通过DNS，但只能实现简单的轮流分配，不能处理故障；

第二如果是基于MS IIS，Windows 2003 server本身就带了负载均衡服务；

第三是硬件方式，通过交换机的功能或专门的负载均衡设备可以实现；

第四种是软件方式，通过一台负载均衡服务器进行，上面安装软件。使用nginx、Apache Httpd Server做负载平衡器。

##3、Tomcat 自身调优
##3.1、禁用DNS查询
当web应用程序要记录客户端的信息时，它也会记录客户端的IP地址或者通过域名服务器查找机器名转换为IP地址。DNS查询需要占用网络，并且包括可能从很多很远的服务器或者不起作用的服务器上去获取对应的IP的过程，这样会消耗一定的时间。
为了消除DNS查询对性能的影响我们可以关闭DNS查询，方式是修改server.xml 文件中的enableLookups参数值。

##3.2、调整线程数
connectionTimeout ：连接超时时长,单位ms
maxThreads：最大线程数，默认200
minSpareThreads：最小空闲线程数
maxSpareThreads：最大空闲线程数
acceptCount：当启动线程满了之后，等待队列的最大长度，默认100
enableLookups：是否启用客户端主机名的DNS反向解析，缺省禁用，建议禁用，就使用客户端IP
就行
compression：是否启用传输压缩机制，建议 "on"，CPU和流量的平衡
compressionMinSize：启用压缩传输的数据流最小值，单位是字节
compressableMimeType：定义启用压缩功能的MIME类型text/html, text/xml, text/css, text/javascrip

##3.3、加速JSP编译速度
当第一次访问一个JSP文件时，它会被转换为Java servlet源码，接着被编译成Java字节码。客户工程师可以控制使用哪个编译器，默认情况下，Tomcat使用命令行javac进行使用的编译器。也可以使用更快的编译器，这里将介绍如何优化它们。

在Tomcat 4.0中可以使用流行而且免费的Jikes编译器。Jikes编译器的速度要高于Sun的Java编译器。首先要安装Jikes（可访问http://oss.software.ibm.com/pub/jikes 获得更多的信息），接着需要在环境变量中设置JIKESPATH包含系统运行时所需的JAR文件。
装好Jikes以后还需要设置让JSP编译servlet使用Jikes，需要修改web.xml文件jspCompilerPlugin的值：
<param-name>jspCompilerPlugin</param-name>
<param-value>org.apache.jasper.compiler.JikesJavaCompiler</param-value>

在Tomcat 4.1（或更高版本），JSP的编译由包含在Tomcat里面的Ant程序控制器直接执行。客户开发人员需要在元素中定义一个名字叫”compiler”，并且在value中有一个支持编译的编译器名字，示例如下：
<param-name>compiler</param-name>
<param-value>jikes</param-value>

由于JSP页面在第一次使用时已经被编译，那么你可能希望在更新新的jsp页面后马上对它进行编译。实际上，这个过程完全可以自动化，因为可以确认的是新的JSP页面在生产服务器和在测试服务器上的运行效果是一样的。

在Tomcat4的bin目录下有一个名为jspc的脚本。它仅仅是运行翻译阶段，而不是编译阶段，使用它可以在当前目录生成Java源文件。它是调试JSP页面的一种有力的手段。

可以通过浏览器访问再确认一下编译的结果。这样就确保了文件被转换成servlet，被编译了可直接执行。这样也准确地模仿了真实用户访问JSP页面，可以看到给用户提供的功能。也抓紧这最后一刻修改出现的bug并且修改它。

Tomcat提供了一种通过请求来编译JSP页面的功能。客户可以在浏览器地址栏中输入http://localhost: 8080/examples/jsp/dates/date.jsp?jsp_precompile=true，这样Tomcat就会编译 data.jsp而不是执行它。此举唾手可得，不失为一种检验页面正确性的捷径

##3.4、NIO 配置
NIO （No-blocking I/O）从JDK 1.4起，NIO API作为一个基于缓冲区，并能提供非阻塞I/O操作的API被引入
TOMCAT可以支持高并发的企业级应用。其中有个很大的原因就是，配置良好的tomcat都会使用APR(Apache Portable Runtime),APR是Apache HTTP Server2.x的核心，它是高度可移植的本地库，它使用高性能的UXIN I/O操作，低性能的java io操作。

但是APR对客户开发人员而言可能稍稍有点难度，在很多OS平台上，可能需要重新编译APR。但是从Tomcat6.0以后, 客户开发人员很容易就可以用NIO的技术来提升tomcat的并发处理能力。但是为什么NIO可以提升tomcat的并发处理能力呢，我们先来看一下java 传统io与 java NIO的差别。

Java 传统的IO操作都是阻塞式的(blocking I/O), 如果有socket的编程基础，你会接触过堵塞socket和非堵塞socket，堵塞socket就是在accept、read、write等IO操作的时候，如果没有可用符合条件的资源，不马上返回，一直等待直到有资源为止。

而非堵塞socket则是在执行select的时候，当没有资源的时候堵塞，当有符合资源的时候，返回一个信号，然后程序就可以执行accept、read、write等操作，一般来说，如果使用堵塞socket，通常我们通常开一个线程accept socket，当读完这次socket请求的时候，开一个单独的线程处理这个socket请求；如果使用非堵塞socket，通常是只有一个线程，一开始是select状，当有信号的时候可以通过多路复用（Multiplexing)技术传递给一个指定的线程池来处理请求，然后原来的线程继续select状态。

最简单的多路复用技术可以通过java管道(Pipe)来实现。换句话说，如果客户端的并发请求很大的时候，客户系统可以使用少于客户端并发请求的线程数来处理这些请求，而这些来不及立即处理的请求会被阻塞在java管道或者队列里面，等待线程池的处理。

在web服务器上阻塞IO(BIO)与NIO一个比较重要的不同是，客户系统使用BIO的时候往往会为每一个web请求引入多线程，每个web请求一个单独的线程，所以并发量一旦上去了，线程数就上去了，CPU就忙着线程切换，所以BIO不合适高吞吐量、高可伸缩的web服务器；而NIO则是使用单线程(单个CPU)或者只使用少量的多线程(多CPU)来接受Socket，而由线程池来处理堵塞在pipe或者队列里的请求。

这样的话，只要OS可以接受TCP的连接，web服务器就可以处理该请求。大大提高了web服务器的可伸缩性。

客户只需要在server.xml里把 HTTP Connector做如下更改：

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
改为
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000"
redirectPort="8443" />
然后启动服务器，如果出现org.apache.coyote.http11.Http11NioProtocol start的提示信息，表示NIO已经启动。其他的配置请参考官方配置文档。

##3.5、其它

Tomcat提供了防止恶意攻击或禁止某些机器访问的设置。

Tomcat提供了两个参数供你配置：RemoteHostValve 和RemoteAddrValve。

通过配置这两个参数，可以让你过滤来自请求的主机或IP地址，并允许或拒绝哪些主机/IP。与之类似的，在Apache的httpd文件里有对每个目录的允许/拒绝指定。

例如你可以把Admin Web application设置成只允许本地访问，设置如下：

<Context path=“/path/to/secret_files” >
<Valve className=“org.apache.catalina.valves.RemoteAddrValve”
allow=“127.0.0.1”deny=““/>
</Context>
如果没有给出允许主机的指定，那么与拒绝主机匹配的主机就会被拒绝，除此之外的都是允许的。与之类似，如果没有给出拒绝主机的指定，那么与允许主机匹配的主机就会被允许，除此之外的都是拒绝的。


##3.6、Java压力测试工具
PerfMa 致力于打造一站式IT系统稳定性保障解决方案，专注于性能评测与调优、故障根因定位与解决，为企业提供一系列技术产品与专家服务，提升系统研发与运行质量。
#社区产品
https://opts.console.perfma.com/