どのようにTomcat 6を最適化するか.0
(1).....................
Webサイトへのアクセスを向上させるために、サーバ側で適切な導入環境を選択することがよくあります.最も簡単なのはtomcatですが、高同時の場合、非常に
時機に乗りやすい.tomcat構成が最適化されていないためです.私は最初にこれらの詳細に注意していません.プロジェクトの性能は環境を構築することによって体現されるのではなく、アルゴリズムの効率、コード実現の合理性、データベースの合理的な使用、最適化技術の使用などを知っています.しかし、導入環境を最適化することは、最も直接的な案と言えるでしょう.現在私が知っているtomcat最適化スキームの1つはtomcatスレッドプールを使用することです.serverでのみxmlで構成を変更すればいいです.コア構成コード:
(2).....................(環境Linux)
tomcatディレクトリに入り、起動します.
./catalina.sh run
端末の画面が開いているのを見て、はっきりしたtomcat 6の起動ログを表示して、圧力テストだけで直接500、残りの調整をしていない情況で通過して、その中でフォームの提出過程の消耗は12秒ぐらいで、少し遅くなって、王老五反応データベースのリンク数は19後に停滞して、それでは引き続き最適化します
2、platformデータソースのスレッド設定を調整する
配布ディレクトリがWebrootであると仮定すると、WebRoot/META-INF/でcontextが確立される.xmlファイル、データソース構成の調整
(注:tomcat 6は、パブリッシュディレクトリのデータソース構成をサポートします.以前のバージョンでは、tomcatインストールパスの下にあるconfディレクトリにファイルパスを変更しました)
context.xmlファイルの内容は次のとおりです.
(注:300世帯を再テストすると、データリンクモニタリングで199までスレッドが解禁されていることがわかりました)
3、tomcat 6応答プールを増設する:
tomcat 6インストールディレクトリの下のconfディレクトリのserverを検索します.xmlファイル、編集
tomcatのデフォルトコネクタをブロックするには:
高スレッドのコネクタを作成するには、次の手順に従います.
(注:応答スレッド数制御、圧縮伝達モード、タイムアウト設定の調整、デバッグモードのマスク)
4、tomcat 6起動メモリを増やす:
tomcat 6インストールディレクトリの下binディレクトリのcatalinaを検索します.shファイルは、以下のように追加されます.
5、oracle応答スレッド数を増やす:
王老五はoracleデータスレッド応答を1000と定めた.これはテスト用であり、oracleリンクリソースを監視している.
(これがどのように設置されたのか知りたいなら、王老五を知っている人は彼と話をして、知らない人はネットで探して、ほほほ)
6、1000戸の圧力測定を開始
水晶がテストを始めた后、确かに既存の10数戸はずっと待っている状态で、R 61本のcpu资源は96%から10%以下に下がって、ハードディスクの明かりは狂ってきらめいて、Desktopシステムの操作は缓和してハードディスクの资源の検査命令を使うことに応答して発见して、ハードディスクの使用资源は100%で、ハードディスクがいっぱいになったことを说明して、系统はキャッシュの操作を探して、ハードディスクとメモリは狂ったように相互作用して
第五章ハードディスクのログの累計を調べて、プラットフォームを斬って春を生みます
検索を通じて、システムのハードディスクリソースが爆発した原因はtomcatログとplatformログが無限に追加された原因で、解決方法は以下の通りです.
1、platformログlog 4 jを調整する.properties
1行目の「log 4 j.rootLogger=DEBUG,A 1,A 2」を「log 4 j.rootLogger=INFO,A 1」に変更
(注:簡単でしょう:-)
2、tomcat 6のログ出力を調整する
次の内容をコメントします.
handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler, 4admin.org.apache.juli.FileHandler, 5host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
(注:行の先頭に番号を付けてください)
3、結晶は引き続き圧力測定を行い、結果は2100戸余りとする
終了:
全体の過程から見ると、PlatFormは耐圧性の面で際立っており、最初から最後まで崩壊していない.すべての失敗したユーザーのエラーメッセージは「time-out」であり、登録応答時間が総プロセスに占める割合がやや高いだけで、調整を続けている.このテストは私のtomcatに対する定義を変えたと言える.各最適化が十分な場合、tomcatの抗亜能力は優秀で、崩壊もしていないが、単一スレッドの応答はずっと非難されている.クラスタユーザーがフォームの応答時間が長いことを反映して、タイムアウト時間を増やさざるを得ない(20秒に決められていたが、1分に調整された).システムの積載量は1つの総合的な過程で、全体の圧力測定の一環の中ですべてのステップはすべて非常に重要で、ある一環の最適化に頼ることができなくて、2100戸の時、データベースのリンクは800線を超えて、システムのcpuの使用量は96%に達して、ハードディスクの資源はほとんど消耗しないで、これは2 Gのメモリが十分に多いものを処理していることを説明します.
Webサイトへのアクセスを向上させるために、サーバ側で適切な導入環境を選択することがよくあります.最も簡単なのはtomcatですが、高同時の場合、非常に
時機に乗りやすい.tomcat構成が最適化されていないためです.私は最初にこれらの詳細に注意していません.プロジェクトの性能は環境を構築することによって体現されるのではなく、アルゴリズムの効率、コード実現の合理性、データベースの合理的な使用、最適化技術の使用などを知っています.しかし、導入環境を最適化することは、最も直接的な案と言えるでしょう.現在私が知っているtomcat最適化スキームの1つはtomcatスレッドプールを使用することです.serverでのみxmlで構成を変更すればいいです.コア構成コード:
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="1000" minSpareThreads="50" maxIdleTime="600000"/>
(2).....................(環境Linux)
tomcatディレクトリに入り、起動します.
./catalina.sh run
端末の画面が開いているのを見て、はっきりしたtomcat 6の起動ログを表示して、圧力テストだけで直接500、残りの調整をしていない情況で通過して、その中でフォームの提出過程の消耗は12秒ぐらいで、少し遅くなって、王老五反応データベースのリンク数は19後に停滞して、それでは引き続き最適化します
2、platformデータソースのスレッド設定を調整する
配布ディレクトリがWebrootであると仮定すると、WebRoot/META-INF/でcontextが確立される.xmlファイル、データソース構成の調整
(注:tomcat 6は、パブリッシュディレクトリのデータソース構成をサポートします.以前のバージョンでは、tomcatインストールパスの下にあるconfディレクトリにファイルパスを変更しました)
context.xmlファイルの内容は次のとおりです.
<?xml version=”1.0″ encoding=”UTF-8″?>
<Context path= “/WebRoot ” privileged= “true” reloadable=”false”>
<Resource name=”sysDataSource” auth=”Container”
type=”javax.sql.DataSource” maxActive=”5000″ maxIdle=”300″ maxWait=”60000″
logAbandoned=”true” username=”yfjz” password=”password”
driverClassName=”oracle.jdbc.driver.OracleDriver”
url=”jdbc:oracle:thin:@10.10.10.XX:1521:al32″ />
<Resource name=”yfjzDataSource” auth=”Container”
type=”javax.sql.DataSource” maxActive=”4000″ maxIdle=”200″ maxWait=”60000″
logAbandoned=”true” username=”yfjz” password=”password”
driverClassName=”oracle.jdbc.driver.OracleDriver”
url=”jdbc:oracle:thin:@10.10.10.XX:1521:al32″ />
(注:300世帯を再テストすると、データリンクモニタリングで199までスレッドが解禁されていることがわかりました)
3、tomcat 6応答プールを増設する:
tomcat 6インストールディレクトリの下のconfディレクトリのserverを検索します.xmlファイル、編集
tomcatのデフォルトコネクタをブロックするには:
<!–
<Connector port=”8080″ protocol=”HTTP/1.1″
connectionTimeout=”20000″
redirectPort=”8443″ />
–>
高スレッドのコネクタを作成するには、次の手順に従います.
<Connector port=”8080″ redirectPort=”8443″
maxHttpHeaderSize=”8192″ useBodyEncodingForURI=”true”
minProcessors=”100″ maxProcessors=”5000″
maxThreads=”5000″ minSpareThreads=”1000″ maxSpareThreads=”4000″
enableLookups=”false” acceptCount=”3500″
compression=”on” compressionMinSize=”2048″
compressableMimeType=”text/html,text/xml,text/javascript,text/css,text/plain”
connectionTimeout=”60000″ disableUploadTimeout=”true” debug=”0″ URIEncoding=”UTF-8″/>
(注:応答スレッド数制御、圧縮伝達モード、タイムアウト設定の調整、デバッグモードのマスク)
4、tomcat 6起動メモリを増やす:
tomcat 6インストールディレクトリの下binディレクトリのcatalinaを検索します.shファイルは、以下のように追加されます.
JAVA_OPTS=” -Xms1400m -Xmx1400m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true ”
5、oracle応答スレッド数を増やす:
王老五はoracleデータスレッド応答を1000と定めた.これはテスト用であり、oracleリンクリソースを監視している.
(これがどのように設置されたのか知りたいなら、王老五を知っている人は彼と話をして、知らない人はネットで探して、ほほほ)
6、1000戸の圧力測定を開始
水晶がテストを始めた后、确かに既存の10数戸はずっと待っている状态で、R 61本のcpu资源は96%から10%以下に下がって、ハードディスクの明かりは狂ってきらめいて、Desktopシステムの操作は缓和してハードディスクの资源の検査命令を使うことに応答して発见して、ハードディスクの使用资源は100%で、ハードディスクがいっぱいになったことを说明して、系统はキャッシュの操作を探して、ハードディスクとメモリは狂ったように相互作用して
第五章ハードディスクのログの累計を調べて、プラットフォームを斬って春を生みます
検索を通じて、システムのハードディスクリソースが爆発した原因はtomcatログとplatformログが無限に追加された原因で、解決方法は以下の通りです.
1、platformログlog 4 jを調整する.properties
1行目の「log 4 j.rootLogger=DEBUG,A 1,A 2」を「log 4 j.rootLogger=INFO,A 1」に変更
(注:簡単でしょう:-)
2、tomcat 6のログ出力を調整する
次の内容をコメントします.
handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler, 4admin.org.apache.juli.FileHandler, 5host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
(注:行の先頭に番号を付けてください)
3、結晶は引き続き圧力測定を行い、結果は2100戸余りとする
終了:
全体の過程から見ると、PlatFormは耐圧性の面で際立っており、最初から最後まで崩壊していない.すべての失敗したユーザーのエラーメッセージは「time-out」であり、登録応答時間が総プロセスに占める割合がやや高いだけで、調整を続けている.このテストは私のtomcatに対する定義を変えたと言える.各最適化が十分な場合、tomcatの抗亜能力は優秀で、崩壊もしていないが、単一スレッドの応答はずっと非難されている.クラスタユーザーがフォームの応答時間が長いことを反映して、タイムアウト時間を増やさざるを得ない(20秒に決められていたが、1分に調整された).システムの積載量は1つの総合的な過程で、全体の圧力測定の一環の中ですべてのステップはすべて非常に重要で、ある一環の最適化に頼ることができなくて、2100戸の時、データベースのリンクは800線を超えて、システムのcpuの使用量は96%に達して、ハードディスクの資源はほとんど消耗しないで、これは2 Gのメモリが十分に多いものを処理していることを説明します.