Tomcat の構成と最適化ソリューションの詳細な説明

サービス.xml

Server.xml 構成ファイルは、コンテナー全体を構成するために使用されます。

<Server> 要素:

構成ファイル全体のルート要素です。 Catalina コンテナ全体を表します。

財産：

className: org.apache.catalina.Server インターフェースを実装するクラス名。標準実装クラスは org.apache.catalina.core.StandardServer クラスです。
ポート: Tomcat サーバーは、Tomcat サーバーのシャットダウンに使用するコマンドをリッスンします (必須)
シャットダウン: Tomcat サーバーをシャットダウンするためにポートに送信されるコマンド。

例：

<Serverport="8005" シャットダウン="シャットダウン">

<Connector> 要素:

コネクタは、クライアント要求を受信し、応答メッセージをクライアントに送り返す役割を担います。

HTTP コネクタ:

財産：

allowTrace: HTTP TRACEメソッドを許可するかどうか。デフォルト値はfalseです。
emptySessionPath: true に設定すると、ユーザーのすべてのパスが / に設定されます。デフォルトは false です。
enableLookups: request と getRemoteHost() を呼び出して DNS クエリを実行し、リモートホストのホスト名を返します。false に設定すると、IP アドレスが直接返されます。
maxPostSize: POST リクエストの最大サイズを指定します。指定しない場合、デフォルト値は 2097152 です。
プロトコル: 値は HTTP1.1 である必要があります。AJP プロセッサを使用する場合、値は AJP/1.3 である必要があります。
proxyName: このコネクタがプロキシ構成で使用されている場合は、request.getServerName() が使用されたときに返されるこのプロパティを指定します。
redirectPort: コネクタが SSL 要求をサポートしていない場合、SSL 要求を受信すると、Catalina コンテナは指定されたポート番号を自動的にリダイレクトして処理します。
スキーム: request.getScheme() によって返されるプロトコルの名前を設定します。SSL コネクタの場合は "https" に設定され、デフォルトは "http" です。
secure: SSLコネクタではtrueに設定できます。デフォルト値はfalseです。
URIEncoding: URL をデコードするために使用される文字エンコーディング。指定されていない場合、デフォルト値は ISO-8859-1 です。
useBodyEncodingForURI: 主にTomcat4.1.xで使用され、URIクエリパラメータをデコードするためにURIEncodingではなくcontentTypeで指定されたエンコーディングを使用するかどうかを示します。デフォルト値はfalseです。
xpoweredBy: trueの場合、Tomcatは仕様で推奨されているヘッダーを使用して、サーブレット仕様バージョンのサポートを示します。デフォルト値はfalseです。
acceptCount: 可能なすべての処理スレッドが使用されている場合にキューに入れることができるリクエストの最大数。キューがいっぱいになると、受信したリクエストはすべて拒否されます。デフォルト値は10です。
bufferSize: コネクタによって作成される入力ストリームバッファのサイズをバイト単位で設定します。デフォルトでは、最大バッファサイズは 2048 バイトです。
compressedMimeType: デフォルトではコンマで区切られた MIME タイプのリスト。デフォルト値はtext/html、text/xml、text/plainです
圧縮: 応答データを圧縮するかどうかを指定します。 off: 圧縮を無効にする、on: 圧縮を許可する（テキストは圧縮される）、force: すべての場合に圧縮する、デフォルト値は off です。
connectionTimeout: 接続タイムアウト値をミリ秒単位で設定します。デフォルト値は60000 = 60秒です
enableUploadTimeOut: サーブレットコンテナが長い接続タイムアウト値を使用できるようにします。これにより、サーブレットの実行を完了する時間が長くなります。デフォルト値は false です。
maxHttpHeaderSize: HTTP 要求および応答ヘッダーの最大サイズ (バイト単位)。デフォルト値は 4096 バイトです。
maxKeepAliveRequest: サーバーが閉じられる前にクライアントから送信されるパイプラインの最大数。デフォルト値は100です
maxSpareThreads: 許可されるアイドルスレッドの最大数。デフォルト値は 50 です。
minSpareThreads: コネクタが最初に起動されたときに作成されるスレッドの数を設定し、少なくともこの数のアイドルスレッドが使用可能であることを保証します。デフォルト値は4です
port: サーバーソケットがリッスンするTCPポート番号。デフォルト値は8080です（必須）
socketBuffer: ソケット出力バッファのサイズを設定します (バイト単位)。-1 はバッファリングを無効にすることを意味します。デフォルト値は 9000 バイトです。
toNoDelay: true の場合、パフォーマンスが向上します。デフォルト値はtrueです
threadPriority: JVM 内のリクエスト処理スレッドの優先度を設定します。デフォルト値はNORMAL-PRIORITYです

例：

<コネクタ 
ポート="8080" 最大HttpHeaderSize="8192" 最大スレッド数="150" 最小スペアスレッド数="25" 最大スペアスレッド数="75" 有効ルックアップ数="false"
リダイレクトポート="8443" 受け入れカウント="100" 接続タイムアウト="20000" アップロードタイムアウトを無効に="true" />

AJP コネクタ:

Apache と Tomcat を統合するために使用されます。Apache は動的コンテンツ要求を受信すると、構成で指定されたポート番号でリッスンしている AJP コネクタコンポーネントに要求を送信します。

財産：

バックログ: すべてのリクエスト処理スレッドが使用されている場合にキューに入れることができるリクエストの最大数。デフォルト値は 10 です。キューがいっぱいになると、すべての要求が拒否されます。
maxSpareThread: 許可されるアイドルスレッドの最大数。デフォルト値は 50 です。
maxThread: スレッドの最大数。デフォルト値は 200 です。
minSpareThreads: コネクタが最初に起動されたときに作成するスレッドの数を設定し、少なくともこの数のアイドルスレッドが利用可能であることを保証します。デフォルト値は 4 です。
port: サーバーソケットのTCPポート番号。デフォルト値は8089です（必須）
topNoDelay: trueの場合、パフォーマンスが向上します。デフォルト値はtrueです。
soTimeout: タイムアウト値

例：

<!—ポート 8089 で AJP1.3 コネクタを定義します -->
<コネクタ ポート =”8089” enableLookups =”false” リダイレクト ポート =”8443” プロトコル =”AJP/1.3” />

<Engine> 要素:

特定のサービスに対するすべてのリクエストを処理します。各サービスには、エンジン要素を 1 つだけ含めることができます。エンジン要素は、このサービスのすべてのコネクタによって受信された要求を受信して処理し、接続に応答を返し、最終的にクライアントに表示する役割を担います。 <Engine> には少なくとも 1 つの <Host> 要素が必要であり、defaultHost で指定された名前と一致する名前を持つ <Host> 属性が少なくとも 1 つ必要です。

財産：

className: org.apache.catalina.Engine インターフェースを実装します。デフォルトの実装クラスは、org.apache.catalina.core.StandardEngine クラスです。
defaultHost: デフォルトのホスト名。値は <Service> の名前の値と一致する必要があります。
name: エンジンの論理名を指定します (必須)
jvmRoute: 負荷分散で使用される識別子。一意である必要があります。

例：

<エンジン名="Cataline" defaultHost="localhst">

<Host> 要素:

仮想ホストを表し、特定の仮想ホストに対するすべてのリクエストを処理します。

財産：

appBase: アプリケーションのベースディレクトリを絶対パスまたは%CATALINA_HOME%からの相対パス名で設定します。
autoDeploy: Tomcat の実行時に、appBase で指定されたディレクトリに新しい Web プログラムを自動的にデプロイするかどうかを示します。デフォルト値は true です。
className: org.apache.catalina.Host インターフェースを実装するクラス。標準実装クラスは org.apache.catalina.core.StandardHost クラスです。
deployOnStartup: Tomcat の起動時に、appBase 属性で指定されたディレクトリにすべての WEB アプリケーションを自動的にデプロイするかどうか。デフォルト値は true です。
name: 仮想ホストのネットワーク名（必須）

標準の Host 実装クラス org.apahce.catalina.core.StandardHost は、追加のプロパティをサポートします。

deployXML: false は、WEB アプリケーション内の context.xml を解析しません。デフォルト値は true です。
unPackWARs: 仮想ホストは、一時的な読み取りと書き込みに使用されるディレクトリのパス名を指定します。設定されていない場合、Tomcat は %CATALINA_HOME%/work ディレクトリに適切なディレクトリを提供します。

例：

<ホスト名="localhst" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">

仮想ホストを設定します。

<ホスト名="xxx" appBase="c:/test">
<コンテンツパス="" docBase="e:/abe"/>
</ホスト名>

<context> 要素:

Web アプリケーションは、現在の Web アプリケーションのすべての要求を処理します。各 <Context> は一意のコンテキストパスを使用する必要があります。

財産：

className: org.apache.catalina.Context インターフェースを実装するクラス、標準実装クラス org.apache.catalina.core.StandardContext クラス
クッキー: セッションにクッキーを適用するかどうか。デフォルト値は true です。
crossContext: クロスドメインアクセスを許可するかどうか。true の場合、プログラム内で ServletContext.getContext() メソッドを呼び出すと、仮想ホスト上の他の Web プログラムのリクエストディスパッチャーが返されます。デフォルト値は false で、getContext() は null を返します。
docBase: ホストの appBase プロパティへの絶対パスまたは相対パス
特権: true、Webアプリケーションがコンテナのサーブレットを使用できるようにする
path: コンテキストパスを指定します。コンテキストパスは仮想ホスト内で一意である必要があります。
reloadable: true、Tomcat の実行中に WEB-INF/classes および WEB-INF/lib ディレクトリに変更があった場合、Tomcat は WEB アプリケーションを自動的にリロードします。便利ですが、コストも高くなります。デフォルト値は false です。通話中にオンにして、公開後にオフにすることができます。
cacheMaxSize: 静的リソースキャッシュの最大値 (KB 単位)。デフォルト値は 10240KB です。
cachingAllowed: 静的リソースのキャッシュを許可するかどうか。デフォルトは true
caseSensitive: デフォルト値は true で、リソースファイル名は大文字と小文字を区別します。false の場合は大文字と小文字を区別しません。
unpackWAR: デフォルトは true
workDir: WEB アプリケーション内のサーブレットの一時的な読み取り/書き込みディレクトリパス名を指定します。設定されていない場合、Tomcatは%CATALINA_HOME%/workディレクトリに適切なディレクトリを提供します。

例：

<コンテンツパス=”/abc” docBase=”d:/xyz” reloadable=”true” />

Tomcat パフォーマンス最適化ソリューションの概要

次のようなシナリオを考えてみましょう。優れたレイアウトデザイン、最新の機能、その他の優れた機能を備えたアプリを開発したとします。しかし、パフォーマンスが不足していると、アプリケーションがどれだけ優れていても顧客に拒否されてしまいます。顧客は常に、アプリケーションのパフォーマンスが向上することを期待しています。

製品で Tomcat サーバーを使用している場合、この記事では Tomcat サーバーのパフォーマンスを向上させるいくつかの方法を紹介します。この記事のリソースを提供してくれた ITWorld の記事に感謝します。よく考えてみると、最新の Tomcat は以前のバージョンに比べてパフォーマンスと安定性が優れていることがわかりました。したがって、常に最新の Tomcat バージョンを使用してください。この記事では、次の手順を使用して Tomcat サーバーのパフォーマンスを向上させます。

JVMヒープメモリサイズを増やす
JRE メモリリークを修正
スレッドプールの設定
圧縮
データベースパフォーマンスチューニング
Tomcat ネイティブライブラリ
その他のオプション

ステップ1 – JVMヒープメモリを増やす

Tomcat を使用したことがある場合、これは単に「メモリオーバーフロー」と呼ばれます。通常、この問題は実際の運用環境で発生します。この問題の原因は、Tomcat がプロセスに使用するメモリが少ないことです。この問題は、TOmcat 構成ファイル (Windows の場合は catalina.bat、Linux の場合は catalina.sh) を構成することで解決できます。この解決策は、JVM のスタックメモリを増やすことで実現されます。つまり、JVM は通常、ガベージコレクターを呼び出さないため、サーバーは Web 要求の処理に集中でき、要求をできるだけ早く完了するように要求できます。「\tomcat server folder\bin\catalina.sh」にあるファイル (catalina.sh) を変更するには、このファイルの構成情報は次のとおりです。

JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8
-サーバー -Xms1024m -Xmx1024m
-XX:新しいサイズ=512m -XX:最大新しいサイズ=512m -XX:パーマサイズ=512m
-XX:MaxPermSize=512m -XX:+DisableExplicitGC"
-Xms – 初期化するスタックメモリを指定します -Xms – 初期化するスタックメモリを指定します -Xmx – 最大スタックメモリを指定します

これらの構成の変更は、Tomcat サーバーを再起動するまで有効になりません。以下では、JRE メモリリークの対処方法について説明します。

ステップ2 – JREメモリリークを修正する

パフォーマンスが低下するもう 1 つの主な原因はメモリリークです。前にも述べたように、パフォーマンスとスケーラビリティを向上させるには、常に最新の Tomcat サーバーを使用してください。今、この言葉は真実になりました。最新の Tomcat バージョン 6.0.26 以降を使用すると、JRE および PermGen のメモリリークを処理するリスナーが含まれているため、このエラーを解決できます。使用されるリスナーは、

<リスナークラス名="org.apache.catalina.core.JreMemoryLeakPreventionListener" />

このリスナーの構成は、「tomcat プロジェクトフォルダー/conf/server.xml」にある server.xml ファイルにあります。次に、接続プロパティ「maxThreads」を調整する方法について説明します。

ステップ3 – スレッドプールのセットアップ

スレッドプールは Web 要求のロード数を指定するため、パフォーマンスを向上させるにはこの部分を慎重に処理する必要があります。これは、コネクタプロパティ「maxThreads」を調整することによって実行できます。 maxThreads の値はトラフィックのサイズに基づいて決定する必要があります。値が低すぎると、すべてのリクエストを処理するためのスレッドが不足し、リクエストは待機状態になり、処理スレッドが解放されたときにのみ処理されます。値が大きすぎると、Tomcat の起動に時間がかかります。したがって、maxThreads に正しい値を設定するのは私たち次第です。

<コネクタ ポート="8080" アドレス="localhost"
最大スレッド数 = "250" 最大Httpヘッダーサイズ = "8192"
空のセッションパス="true" プロトコル="HTTP/1.1"
enableLookups="false" リダイレクトポート="8181" 受け入れカウント="100"
接続タイムアウト="20000" アップロードタイムアウトを無効に="true" />

上記の構成では、maxThreads 値は「250」に設定されており、これはサーバーが処理できる同時リクエストの最大数を指定します。指定しない場合、このプロパティのデフォルト値は「200」になります。別のプロセスが解放されてリクエストを処理できるようになるまで、追加の同時リクエストには「接続拒否」エラーが発生します。エラーは次のようになります。

org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: すべてのスレッド (250) が
現在ビジー状態、待機中。maxThreads (250) を増やすか、サーブレットの状態を確認してください。

アプリケーションが上記のエラーをプロンプト表示した場合は、上記のエラーが単一のリクエストに時間がかかりすぎていることが原因であるかどうかを必ず確認してください。この問題の原因は、データベース接続が解放されない場合、プロセスが他のリクエストを処理できないことがあるためです。

注: リクエスト数が「750」を超える場合、maxThreads 属性値を「750」に設定するのではなく、「Tomcat Cluster」の複数のインスタンスを使用する方がよいことを意味します。つまり、リクエストが「1000」ある場合、単一の Tomcat インスタンスの場合に maxThreads = 1000 を設定するのではなく、両方の Tomcat インスタンスで「maxThreads = 500」が設定されます。

私の経験では、さまざまな環境でアプリケーションをテストすることで正確な値がわかります。次に、MIME タイプを圧縮する方法について説明します。

ステップ4 - 圧縮

Tomcat には、server.xml 構成ファイルで設定することで圧縮を有効にするオプションがあります。圧縮は以下のようにコネクタ設定で行うことができます。

 <コネクタ ポート="8080" プロトコル="HTTP/1.1"
 接続タイムアウト = "20000"
 リダイレクトポート="8181" 圧縮="500"
 圧縮可能なMimeType="text/html、text/xml、text/plain、application/octet-stream" />

以前の構成では、ファイルのサイズが 500 バイト以上の場合にのみファイルが圧縮されます。必要なサイズに達したときにファイルが圧縮されない場合は、プロパティ compression="on" を設定します。それ以外の場合、Tomcat のデフォルト設定は「オフ」になります。次に、データベースを調整する方法について説明します。

ステップ 5 - データベースパフォーマンスのチューニング

データベースクエリの実行を待機している間、Tomcat のパフォーマンスは低下します。今日のほとんどのアプリケーションでは、「名前付きクエリ」を含む可能性のあるリレーショナルデータベースが使用されています。その場合、Tomcat は起動時にデフォルトで名前付きクエリをロードし、パフォーマンスが向上する可能性があります。もう 1 つの重要な点は、すべてのデータベース接続が適切に閉じられていることを確認することです。データベース接続プールに正しい値を設定することも非常に重要です。ここで言う値とは、Resource 要素の最大アイドル数 (maxIdle)、最大接続数 (maxActive)、最大接続確立待機時間 (maxWait) 属性の値です。構成の依存関係とアプリケーションの要件のため、この記事では正しい値を指定することはできません。データベースパフォーマンステストを呼び出すと、正しい値を見つけることができます。

ステップ 6 – Tomcat ネイティブライブラリ

Tomcat のネイティブライブラリは Apache Portable Runtime (APR) に基づいており、プログラマーに優れたスケーラビリティとパフォーマンスを提供し、ネイティブサーバーテクノロジを製品操作に統合して最適なパフォーマンスを発揮するのに役立ちます。インストール手順については、「Tomcat Native Library – (APR) インストール」を参照してください。

ステップ7 – その他のオプション

オプションは次のとおりです:

ブラウザのキャッシュを有効にすると、Web アプリフォルダーに保存されている静的コンテンツがより速く読み取られ、全体的なパフォーマンスが大幅に向上します。
Tomcat サーバーは起動のたびに自動的に再起動します。
一般的に、HTTPS リクエストは HTTP リクエストよりも遅くなります。より高いセキュリティが必要な場合は、速度が遅くても HTTPS を選択する必要があります。

TOMCAT を設定して GZIP 圧縮を有効にする

原則の紹介

HTTP 圧縮は、Web サイトの閲覧速度を大幅に向上させます。その原理は、クライアントがサーバーから対応するリソースを要求した後、リソースファイルがサーバーから圧縮され、クライアントに出力されるというものです。クライアントのブラウザーは、解凍と閲覧を担当します。

通常のブラウジングプロセス（HTML、CSS、Javascript、テキスト）と比較すると、トラフィックを約 40% 節約できます。さらに重要なのは、CGI、PHP、JSP、ASP、サーブレット、SHTML などによって出力されるものを含む、動的に生成された Web ページを圧縮でき、圧縮効率も非常に高いことです。

設定方法

Tomcat 5.0 以降のバージョンでは、gzip 圧縮形式を使用した出力コンテンツの圧縮がサポートされています。

%TOMCAT_HOME%/conf/server.xml を変更し、ノードを次のように修正します。

<コネクタ ポート="80" プロトコル="HTTP/1.1" 
接続タイムアウト = "20000" 
リダイレクトポート="8443" 実行者="tomcatThreadPool" URIEncoding="utf-8" 
圧縮="オン" 
圧縮最小サイズ="50" 圧縮ユーザーエージェントなし="gozilla、traviata" 
圧縮可能なMimeType="text/html、text/xml、text/javascript、text/css、text/plain" />

上記のノードのプロパティからわかるように、gzip圧縮機能を使用するには、コネクタノードに次のプロパティを追加する必要があります。

compression="on" は圧縮をオンにします
compressionMinSize="50" は圧縮された出力コンテンツサイズを有効にします。デフォルトは 2KB です。
noCompressionUserAgents="gozilla, traviata" 以下のブラウザでは圧縮は有効になっていません
compressedMimeType="text/html,text/xml,text/javascript,text/css,text/plain" 圧縮する必要があるリソースの種類

試験方法

TOMCAT 圧縮機能を有効にした後、圧縮が効果的かどうかをテストするにはどうすればよいですか?

まず、Tomcat はブラウザのリクエストヘッダーの accept-encoding に基づいて、ブラウザが圧縮をサポートしているかどうかを判断します。この値に gzip が含まれている場合、ブラウザは gzip 圧縮されたコンテンツの閲覧をサポートしていることを意味します。圧縮が有効かどうかを確認するには、2 つの方法があります。

ブラウザから圧縮設定が有効になっているサーバーに直接アクセスし、パケットキャプチャツールでキャプチャしたデータパケットを表示することができます。理解できない内容が多い場合は、圧縮機能が有効になっていることを意味します。

プログラムを通じてリクエストをシミュレートする

httpclient を使用して簡単なテストプログラムを作成します。コードは次のとおりです。

@テスト 
パブリックボイドtestGzip() { 
HttpClient を新しい HttpClient() に追加します。 
GetMethod getMethod = new GetMethod("http://localhost/admin.jsp"); 
試す { 
getMethod.addRequestHeader("accept-encoding", "gzip,deflate"); 
getMethod.addRequestHeader("user-agent","Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar; Maxthon 2.0)"); 
int 結果 = httpClient.executeMethod(getMethod); 
結果 == 200 の場合 
System.out.println(getMethod.getResponseContentLength()); 
文字列 html = getMethod.getResponseBodyAsString(); 
System.out.println(html); 
System.out.println(html.getBytes().length); 
} 
} キャッチ (HttpException e) { 
e.printStackTrace(); 
} キャッチ (IOException e) { 
e.printStackTrace(); 
ついに 
getMethod.releaseConnection(); 
} 
}

この junit プログラムを実行して、出力結果を確認してください。出力結果に文字化けが見られ、印刷されたコンテンツの長さが実際の長さよりはるかに短い場合、設定が有効であることを意味します。他の検証ツールを使用すると、Web サイトの閲覧速度が大幅に向上することがわかります。

注: コンテンツが圧縮されていない場合は、compressionMinSize のサイズを調整することを検討してください。要求されたリソースがこの値より小さい場合、圧縮は有効になりません。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。

以下もご興味があるかもしれません: