Tomcat -- パフォーマンスの最適化

1. JVM の最適化

1.

2. ガベージ コレクション戦略の最適化。

2.server.xmlのコネクタ最適化(コネクタはHTTPリクエスト処理に関わるコンテナです。3つのコンテナの初期化順序はサーバー→サービス→コネクタ)

(1)NIOの使用を指定HTTP リクエストを受け入れるモデル

(2) http コネクタの最適化、処理スレッド数を指定

(3) スレッド プール

(4) その他の一般設定

3. セッションの有効期限を設定

4. Apr プラグ-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 -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4"

パラメータは次のとおりです:
-Xmx3550m: 使用可能な最大値を設定しますJVM のメモリを 3550M に増やします。最大ヒープ サイズは、利用可能な物理メモリの 80% を超えてはなりません
-Xms3550m: メモリが 3550m になるように JVM を設定します。この値を -Xmx と同じに設定すると、ガベージ コレクションのたびに JVM がメモリを再割り当てするのを避けることができます。
-Xmn2g: 若い世代のサイズを 2G に設定します。全体のヒープ サイズ = 若い世代のサイズ + 古い世代のサイズ + 永続世代のサイズ。通常、永続世代のサイズは 64m に固定されているため、若い世代を増やすと古い世代のサイズが小さくなります。この値は、システムのパフォーマンスに大きな影響を与えます。Sun では、ヒープ全体の 3/8 の構成を公式に推奨しています。
-Xss128k: 各スレッドのスタック サイズを設定します。 JDK5.0 以降、各スレッドのスタック サイズは 1M 以前は、各スレッドのスタック サイズは 256K でした。より多くのアプリケーション スレッドに必要なメモリ サイズを調整します。同じ物理メモリの下で、この値を減らすと、より多くのスレッドが生成される可能性があります。ただし、オペレーティング システムにはプロセス内のスレッド数に制限があり、経験値は 3000 ～ 5000 程度です。
-XX:NewRatio=4: 古い世代 (永続世代を除く) に対する若い世代 (Eden と 2 つの Survivor エリアを含む) の比率を設定します。 4 に設定すると、若い世代と古い世代の比率は 1:4 になり、若い世代がスタック全体の 1/5 を占めます
-XX:SurvivorRatio=4: Eden 領域のサイズ比率を設定し、若い世代のサバイバーエリア。 4 に設定すると、2 つの Survivor エリアと 1 つの Eden エリアの比率は 2:4 となり、1 つの Survivor エリアが若い世代全体の 1/6 を占めます
-XX:MaxPermSize=16m: 永続世代のサイズを 16m に設定します。
-XX:MaxTenuringThreshold=0: ガベージの最大存続期間を設定します。 0 に設定すると、若い世代のオブジェクトは Survivor 領域を経由せずに直接古い世代に入ります。古い世代が多数あるアプリケーションの場合、効率を向上させることができます。この値をより大きな値に設定すると、若い世代のオブジェクトが Survivor 領域に複数回コピーされるため、若い世代でのオブジェクトの生存時間が長くなり、若い世代で再利用される可能性が高まります。

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: このオプションを設定すると、パラレル コレクターは、ターゲット システムで指定された最小応答時間または収集頻度を達成するために、若い世代領域のサイズと対応する Survivor 領域の比率を自動的に選択します。この値のパラレル コレクターは常にオープンです。

コンカレントコレクター (応答時間優先)
例: java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSoupGC
-XX:+UseConcMarkSweatGC: コンカレントコレクション用に古い世代を設定します。テストでこれを構成した後、-XX:NewRatio=4 の構成は不明な理由で失敗しました。したがって、現時点では、若い世代のサイズには -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) 共有セッションを保存するためにサードパーティを使用します
現在、最も一般的に使用されている方法は memcached を使用することです。 memcached-sesson-manager を使用して共有セッションを管理します。 Tomcat セッション管理
リファレンス (MSM を使用して Tomcat クラスター セッションを管理する)
3) セッション要件がそれほど強くない場合には、スティッキー セッション戦略を使用します。 (課金を伴わない、失敗しても再リクエストが許可される、など), nginx または apache によって、同じユーザーのセッションを同じ Tomcat に引き継ぐことができます。これは、現在使用されている、いわゆるセッション スティッキー戦略です。
参考: (Tomcat セッション スティッキー)
nginx にはデフォルトでセッション スティッキー モジュールが含まれていないため、再インストールする必要があります (Windows で再コンパイルする方法がわかりません)
利点は次のとおりです。処理効率ははるかに高いですが、セッション要件が強い場合には適さないという欠点があります

以上がTomcat -- パフォーマンスの最適化の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。