Tomcat--성능 최적화

1. JVM 최적화

1.

2. 가비지 수집 전략 최적화.

2. server.xml의 커넥터 최적화(커넥터는 HTTP 요청 처리와 관련된 컨테이너입니다. 세 컨테이너의 초기화 순서는 서버->서비스->커넥터입니다)

(1) NIO 사용을 지정합니다. HTTP 요청을 수락하는 모델

(2) http 커넥터 최적화, 처리 스레드 수 지정

(3) 스레드 풀

(4) 기타 일반 설정

3. 세션 만료 시간 설정

4. 4월 플러그 -in은 Tomcat 성능 향상

5. 클러스터

6. 문제 위치

1. JVM 최적화

linux는 TOMCAT_HOME/bin/catalina.sh를 수정하고

JAVA_OPTS="-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m -Duser.timezone=Asia/Shanghai"

를 추가합니다.windows는 TOMCAT_HOME/bin/catalina.bat를 수정하고

set JAVA_OPTS=-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m

1. 메모리 조정
메모리 모드 설정은 catalina.sh에 있습니다. 후속 시작 매개변수는 JAVA_OPTS를 JVM의 시작 매개변수로 처리하므로 JAVA_OPTS 변수만 조정하세요.

구체적인 설정은 다음과 같습니다:
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4"

매개변수는 다음과 같습니다:
-Xmx3550m: 사용 가능한 최대값을 설정합니다. JVM의 메모리를 3550M으로 늘렸습니다. 최대 힙 크기는 사용 가능한 물리적 메모리의 80%를 초과할 수 없습니다.
-Xms3550m: 메모리가 3550m가 되도록 JVM을 설정합니다. 이 값은 -Xmx와 동일하게 설정하여 각 가비지 수집이 완료된 후 JVM이 메모리를 재할당하는 것을 방지할 수 있습니다.
-Xmn2g: Young Generation 크기를 2G로 설정합니다. 전체 힙 크기 = 젊은 세대 크기 + 이전 세대 크기 + 영구 세대 크기. 영속 세대는 일반적으로 64m로 고정된 크기를 가지므로 Young 세대를 늘리면 Old 세대의 크기가 줄어듭니다. 이 값은 시스템 성능에 큰 영향을 미칩니다. Sun은 공식적으로 전체 힙의 3/8로 구성할 것을 권장합니다.
-Xss128k: 각 스레드의 스택 크기를 설정합니다. JDK5.0 이후에는 각 스레드의 스택 크기가 1M입니다. 과거에는 각 스레드의 스택 크기가 256K였습니다. 더 많은 애플리케이션 스레드에 필요한 메모리 크기를 조정합니다. 동일한 실제 메모리에서 이 값을 줄이면 더 많은 스레드가 생성될 수 있습니다. 하지만 운영체제에서는 여전히 프로세스의 스레드 수에 제한이 있어 무한정 생성할 수 없습니다. 경험치는 3000~5000 정도입니다.
-XX:NewRatio=4: Young Generation(Eden 및 Survivor 영역 2개 포함)과 Old Generation(Persist Generation 제외)의 비율을 설정합니다. 4로 설정하면 Young Generation과 Old Generation의 비율이 1:4가 되어 Young Generation이 전체 스택의 1/5을 차지합니다.
-XX:SurvivorRatio=4: Eden 영역의 크기 비율을 설정하고 젊은 세대의 생존자 영역. 4로 설정하면 두 개의 Survivor 영역과 하나의 Eden 영역의 비율이 2:4이고 하나의 Survivor 영역이 전체 젊은 세대의 1/6을 차지합니다.
-XX:MaxPermSize=16m: 영구 세대 크기를 16m로 설정합니다.
-XX:MaxTenuringThreshold=0: 쓰레기의 최대 수명을 설정합니다. 0으로 설정하면 Young Generation 객체가 Survivor 영역을 거치지 않고 Old Generation으로 직접 진입하게 됩니다. 이전 세대 수가 많은 애플리케이션의 경우 효율성이 향상될 수 있습니다. 이 값을 더 큰 값으로 설정하면 Young Generation 객체가 Survivor 영역에 여러 번 복사되므로 Young Generation에서 해당 객체의 생존 시간이 늘어나고 Young Generation에서 재활용될 가능성이 높아집니다.

2. 가비지 수집 전략 튜닝
가비지 수집 설정은 catalina.sh에도 있습니다. JAVA_OPTS 변수를 조정하세요.
구체적인 설정은 다음과 같습니다.
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100"
구체적인 가비지 수집 전략과 해당 전략의 매개변수는 다음과 같습니다.

직렬 수집기(JDK1.5 이전의 주요 재활용 방법)
-XX:+UseSerialGC: 직렬 수집기 설정
병렬 수집기(처리량 우선순위)
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX: MaxGCPauseMillis =100

-XX:+UseParallelGC: 가비지 수집기를 병렬 수집기로 선택합니다. 이 구성은 젊은 세대에게만 유효합니다. 즉, 위의 구성에서 젊은 세대는 동시 수집을 사용하고, 구세대는 여전히 직렬 수집을 사용합니다.
-XX:ParallelGCThreads=20: 병렬 수집기의 스레드 수, 즉 동시에 가비지 수집을 수행하는 스레드 수를 구성합니다. 이 값은 프로세서 수와 동일하게 구성하는 것이 가장 좋습니다.
-XX:+UseParallelOldGC: 구세대 가비지 수집 방법을 병렬 수집으로 구성합니다. JDK6.0은 이전 세대의 병렬 수집을 지원합니다.
-XX:MaxGCPauseMillis=100: 각 젊은 세대의 가비지 수집에 대한 최대 시간을 설정합니다. 이 시간을 충족할 수 없으면 JVM은 이 값을 충족하도록 자동으로 젊은 세대 크기를 조정합니다.
-XX:+UseAdaptiveSizePolicy: 이 옵션을 설정한 후 병렬 수집기는 대상 시스템에서 지정한 최소 응답 시간 또는 수집 빈도를 달성하기 위해 Young Generation 영역 크기와 해당 Survivor 영역 비율을 자동으로 선택합니다. 이 값을 갖는 병렬 컬렉터는 항상 열려 있습니다.

동시 수집기(응답 시간 우선 순위)
예: java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC
-XX:+UseConcMarkSweepGC: 동시 수집을 위해 이전 세대를 설정합니다. 테스트에서 이를 구성한 후 알 수 없는 이유로 -XX:NewRatio=4 구성이 실패했습니다. 따라서 이때 Young Generation 크기에 대해서는 -Xmn 설정을 사용하는 것이 가장 좋습니다.
-XX:+UseParNewGC: 젊은 세대를 병렬 수집으로 설정합니다. CMS 컬렉션과 동시에 사용할 수 있습니다. JDK5.0 이상에서는 시스템 구성에 따라 JVM이 자체적으로 설정하므로 이 값을 설정할 필요가 없다.
-XX:CMSFullGCsBeforeCompaction: 동시 수집기는 메모리 공간을 압축하고 구성하지 않으므로 일정 시간 동안 실행한 후 "조각"이 생성되어 작업 효율성이 떨어집니다. 이 값은 메모리 공간을 압축하고 정리하기 위해 GC를 몇 번 실행할 것인지를 설정합니다.
-XX:+UseCMSCompactAtFullCollection: 이전 세대의 압축을 켭니다. 성능에 영향을 미칠 수 있지만 조각화를 제거할 수 있습니다

3. 요약
메모리 설정에서 어느 정도 절충이 필요합니다
1) 메모리가 클수록 일반적인 상황에서는 처리 효율성이 높아지지만 동시에 가비지 수집 수행 시간 시간이 오래 걸릴수록 이 기간 동안의 처리 효율성은 필연적으로 영향을 받습니다.
2)在大多数的网络文章中都推荐 Xmx和Xms设置为一致，说是避免频繁的回收，这个在测试的时候没有看到明显的效果，内存的占用情况基本都是锯齿状的效果，所以这个还要根据实际情况来定。

二、Server.xml的Connection优化

提高Tomcat的并发能力一些方法

1、Apache + Tomcat 结合起来用Apache 负责静态页面，Tomcat负责动态页面，同时减少connectionTimeout的时间，以应对并发量大线程回收来不及的情况。
2、压力过大的问题，可以做负载均衡，一个TOMCAT无论如何也不可能担当如此多的线程负载，而且JVM过大，其内存管理成本将显著加大。2G的内存，做3-4个TOMCAT实例（512RAM*4），更为科学合理。
3、数据库连接池，不少人，都推荐使用C3P0，能提高访问数据库的并发性能好几倍。（有博文称使用tomcat自带的jdbc-pool更好，还没试过）
4、采用Tomcat集群可以最大程度的发挥服务器的性能，可以在配置较高的服务器上部署多个Tomcat，也可以在多台服务器上分别部署 Tomcat，Apache和Tomcat整合的方式还是JK方式。经过验证，系统对大用户量使用的响应方面，Apache+3Tomccat集群> Apache+2Tomcat集群> Apache集成Tomcat >单个Tomcat。并且采用Apache+多Tomcat集群的部署方式时，如果一个Tomcat出现宕机，系统可以继续使用，所以在硬件系统性能足够优越的情况下，需要尽量发挥软件的性能，可以采用增加Tomcat集群的方式。
5. 打开KeepAlive支持
KeepAlive on, KeepAliveTimeout 15 MaxKeepAliveRequests 1000
根据实际经验，通过Apache和Tomcat集群的方式提高系统性能的效果十分明显，这种方式可以最大化的利用硬件资源，通过多个Tomcat的处理来分担单Tomcat时的压力。
web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。

1.指定使用NIO模型来接受HTTP请求 
protocol="org.apache.coyote.http11.Http11NioProtocol" 指定使用NIO模型来接受HTTP请求。默认是BlockingIO，配置为protocol="HTTP/1.1" 
acceptorThreadCount="2" 使用NIO模型时接收线程的数目 

2、指定处理线程数目 

<Connector port="80" protocol="HTTP/1.1" maxThreads="600" minSpareThreads="100" maxSpareThreads="500" acceptCount="700"
connectionTimeout="20000" redirectPort="8443" />

maxThreads="600"       ///最大线程数
minSpareThreads="100"///初始化时创建的线程数
maxSpareThreads="500"///一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。
acceptCount="700"//指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理

这里是http connector的优化，如果使用apache和tomcat做集群的负载均衡，并且使用ajp协议做apache和tomcat的协议转发，那么还需要优化ajp connector。

<Connector port="8009" protocol="AJP/1.3" maxThreads="600" minSpareThreads="100" maxSpareThreads="500" acceptCount="700"
connectionTimeout="20000" redirectPort="8443" />

 3、线程池

由于tomcat有多个connector，所以tomcat线程的配置，又支持多个connector共享一个线程池。

首先。打开/conf/server.xml，增加

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="500" minSpareThreads="20" maxIdleTime="60000" />

最大线程500（一般服务器足以），最小空闲线程数20，线程最大空闲时间60秒。

然后，修改节点，增加executor属性，executor设置为线程池的名字：

<Connector executor="tomcatThreadPool" port="80" protocol="HTTP/1.1"  connectionTimeout="60000" keepAliveTimeout="15000" maxKeepAliveRequests="1"  redirectPort="443" />

可以多个connector公用1个线程池，所以ajp connector也同样可以设置使用tomcatThreadPool线程池。

 4.其它常用设置 
maxHttpHeaderSize="8192" http请求头信息的最大程度，超过此长度的部分不予处理。一般8K。 
URIEncoding="UTF-8" 指定Tomcat容器的URL编码格式。不要遗漏URIEncoding=”GBK”，能使页面url传递中文参数时保证正确。
disableUploadTimeout="true" 上传时是否使用超时机制 
enableLookups="false"--是否反查域名，默认值为true。为了提高处理能力，应设置为false 
compression="on"   打开压缩功能 。压缩会增加Tomcat负担，最好采用Nginx + Tomcat 或者 Apache + Tomcat 方式，压缩交由Nginx/Apache 去做。
compressionMinSize="10240" 启用压缩的输出内容大小，默认为2KB 
noCompressionUserAgents="gozilla, traviata"   对于以下的浏览器，不启用压缩 
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" 哪些资源类型需要压缩 
5.小结 
关于Tomcat的Nio和ThreadPool，本身的引入就提高了处理的复杂性，所以对于效率的提高有多少，需要实际验证一下。 

三、设置session过期时间

conf\web.xml中通过参数指定：

    <session-config>   
        <session-timeout>180</session-timeout>     
    </session-config> 
单位为分钟。

四、Apr插件提高Tomcat性能

  Tomcat可以使用APR来提供超强的可伸缩性和性能，更好地集成本地服务器技术.

  APR(Apache Portable Runtime)是一个高可移植库，它是Apache HTTP Server 2.x的核心。APR有很多用途，包括访问高级IO功能(例如sendfile,epoll和OpenSSL)，OS级别功能(随机数生成，系统状态等等)，本地进程管理(共享内存，NT管道和UNIX sockets)。这些功能可以使Tomcat作为一个通常的前台WEB服务器，能更好地和其它本地web技术集成，总体上让Java更有效率作为一个高性能web服务器平台而不是简单作为后台容器。

  在产品环境中，特别是直接使用Tomcat做WEB服务器的时候，应该使用Tomcat Native来提高其性能  

  要测APR给tomcat带来的好处最好的方法是在慢速网络上（模拟Internet），将Tomcat线程数开到300以上的水平，然后模拟一大堆并发请求。
  如果不配APR，基本上300个线程狠快就会用满，以后的请求就只好等待。但是配上APR之后，并发的线程数量明显下降，从原来的300可能会马上下降到只有几十，新的请求会毫无阻塞的进来。
  在局域网环境测，就算是400个并发，也是一瞬间就处理/传输完毕，但是在真实的Internet环境下，页面处理时间只占0.1%都不到，绝大部分时间都用来页面传输。如果不用APR，一个线程同一时间只能处理一个用户，势必会造成阻塞。所以生产环境下用apr是非常必要的。

(1)安装APR tomcat-nativeapr-1.3.8.tar.gz   安装在/usr/local/apr
    #tar zxvf apr-1.3.8.tar.gz
    #cd apr-1.3.8#./configure;make;make install
    
    apr-util-1.3.9.tar.gz  安装在/usr/local/apr/lib
    #tar zxvf apr-util-1.3.9.tar.gz
    #cd apr-util-1.3.9  
    #./configure --with-apr=/usr/local/apr ----with-java-home=JDK;make;make install
    
    #cd apache-tomcat-6.0.20/bin  
    #tar zxvf tomcat-native.tar.gz  
    #cd tomcat-native/jni/native  
    #./configure --with-apr=/usr/local/apr;make;make install
    
  (2)设置 Tomcat 整合 APR
    修改 tomcat 的启动 shell （startup.sh），在该文件中加入启动参数：
      CATALINA_OPTS="$CATALINA_OPTS -Djava.library.path=/usr/local/apr/lib" 。
 
  (3)判断安装成功:
    如果看到下面的启动日志，表示成功。      2007-4-26 15:34:32 org.apache.coyote.http11.Http11AprProtocol init

5. 클러스터 솔루션

단일 Tomcat의 처리 성능은 제한되어 있습니다. 동시성이 크면 로드 밸런싱을 위해 여러 세트를 배포해야 합니다.

클러스터의 핵심은 다음과 같습니다.
1. 로드 측면을 소개합니다.
소프트 로드는 nginx 또는 apache를 사용하여 수행할 수 있으며 주로 배포 기능을 사용합니다.
참고:
(nginx 로드)
(apache 로드) )

2. 공유 세션 처리
현재 처리 방법은 다음과 같습니다.
1) Tomcat 자체의 세션 복제 기능 사용
참조(세션 복제 구성)
구성이 간단하다는 것이 솔루션의 장점입니다. 단점은 클러스터 수가 크면 세션 복제 시간이 길어져 응답 효율성에 영향을 미친다는 것입니다.
2) 제3자를 사용하여 공유 세션을 저장합니다.
현재 가장 일반적으로 사용되는 방법은 memcached를 사용하는 것입니다. memcached-sesson-manager를 사용하여 공유 세션을 관리합니다. Tomcat 세션 관리
참조(MSM을 사용하여 Tomcat 클러스터 세션 관리)
3) 고정 세션 전략을 사용합니다.
세션 요구 사항이 너무 강력하지 않은 경우 (과금 관련 없음, 실패 시 재요청 허용 등), nginx나 apache에 의해 동일한 사용자의 세션이 동일한 Tomcat으로 넘겨질 수 있습니다. 이는 현재 사용되는 소위 세션 고정 전략입니다.
참조: (tomcat 세션 고정)
nginx에는 기본적으로 세션 고정 모듈이 포함되어 있지 않으며 다시 설치해야 합니다. (Windows에서는 다시 컴파일하는 방법을 모르겠습니다.)
장점은 다음과 같습니다. 처리 효율성은 훨씬 높지만 세션 요구 사항이 강한 경우에는 적합하지 않다는 단점이 있습니다.

3. 각 사이트에 하나의 인스턴스가 있습니다. 여러 Tomcat을 시작하세요.

4. 요약
위는 클러스터 구현의 핵심입니다. 1과 2를 조합하여 사용할 수 있습니다. 구체적인 시나리오를 분석해 보겠습니다~

6. 문제 위치

프로세스 Tomcat은 동시성, 세션 수, 메모리 및 메모리 재활용과 같은 여러 측면으로 인해 발생합니다. 문제가 발생한 후에는 분석해야 합니다.

1. Tomcat 세션 수에 대하여
Tomcat의 웹 관리 인터페이스에서 직접 볼 수도 있고
Tomcat의 자체 관리보다 약간 더 많은 기능을 갖춘 타사 도구인 Lambda Probe의 도움으로 볼 수도 있습니다.

2. Tomcat의 메모리 사용량을 모니터링합니다.
JDK와 함께 제공되는 jconsole을 사용하여 메모리 사용량, 스레드 상태, 현재 로드된 총 클래스 수 등을 명확하게 확인합니다.
JDK와 함께 제공되는 jvisualvm은 자동으로 GC 등의 플러그인을 다운로드하고 더욱 풍부한 정보를 확인하세요. 로컬 Tomcat을 분석하는 경우 메모리 샘플링을 수행하고 각 클래스의 사용량을 확인할 수도 있습니다.

3. 클래스의 로딩 상태와 객체의 재활용 상태를 인쇄합니다.
이는 시작 매개변수를 구성하여 인쇄할 수 있습니다. JVM 정보(화면(기본적으로 catalina.log) 또는 파일), 특정 매개변수는 다음과 같습니다:
-XX:+PrintGC: 출력 형식: [GC 118250K->113543K(130112K), 0.0094143 초] [전체 GC 121376K ->10414K(130112K), 0.0650971초]
-XX:+PrintGCDetails: 출력 형식: [GC [DefNew: 8614K->781K(9088K), 0.0123035초] 118250K->113 543K( 1301 12K), 0.0124633초] [GC [DefNew: 8614K->8614K(9088K), 0.0000665초][Tenured: 112761K->10414K(121024K), 0.0433488초] 121376K-& gt;10414K(130112K), 0.0436268초 ]
-XX:+PrintGCTimeStamps -XX:+PrintGC: PrintGCTimeStamps는 위의 두 가지와 혼합될 수 있습니다. 출력 형식은 11.851: [GC 98328K->93620K(130112K), 0.0082960초]
-XX:+PrintGCApplicationConcurrentTime: 각 가비지 컬렉션을 인쇄하기 전에 프로그램은 인터럽트 실행 시간을 갖지 않습니다. 위의 내용과 혼합될 수 있습니다. 출력 형식: 응용 프로그램 시간: 0.5291524초
-XX:+PrintGCApplicationStoppedTime: 가비지 수집 중에 프로그램이 일시 중지된 시간을 인쇄합니다. 위의 내용과 혼합될 수 있습니다. 출력 형식: 애플리케이션 스레드가 중지된 총 시간: 0.0468229초
-XX:PrintHeapAtGC: GC 전후의 자세한 스택 정보를 인쇄합니다.
-Xloggc:filename: 위 내용과 함께 사용되며, 관련 로그 정보를 파일에 기록하여 분석합니다.

-verbose:class는 로드된 클래스의 상태를 모니터링합니다.
-verbose:gc는 가상 머신에서 메모리 재활용이 발생할 때 출력 장치에 정보를 표시합니다.
-verbose:jni는 일반적으로 jni 진단에 사용되는 기본 메서드 호출의 관련 상황을 출력합니다. 호출 오류 메시지

4. JMS 원격 모니터링 추가
LAN의 다른 컴퓨터에 배포된 Tomcat의 경우 JMX 모니터링 포트를 열 수 있습니다. LAN의 다른 컴퓨터는 이 포트를 통해 일반적으로 사용되는 일부 매개 변수를 볼 수 있습니다. 복잡한 기능은 지원되지 않음), JVM 시작 매개변수에서 구성할 수도 있습니다. 구성은 다음과 같습니다:
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname= 192.168.71.38 주로 인트라넷 주소 127.0.0.1에 대한 잘못된 모니터링을 방지하기 위해 JVM JMS 모니터링 IP 주소를 설정합니다.
-Dcom.sun.management.jmxremote.port=1090 JVM JMS 모니터링 설정 port
- Dcom.sun.management.jmxremote.ssl=false JVM 설정 JMS 모니터링은 SSL에서 실용적이지 않습니다.
-Dcom.sun.management.jmxremote.authenticate=false JVM 설정 JMS 모니터링에는 인증이 필요하지 않습니다.

5 . 전문 분석 도구
IBM ISA, JProfiler 등이 있습니다. 구체적인 모니터링 및 분석 방법은 온라인에서 검색해 보세요.

위 내용은 Tomcat--성능 최적화의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!