1.概要
大規模なJavaのWebプロジェクトのために、メモリのオーバーフローが発生した場合、操作の応答時間が長くなり、あなたが私のチュートリアルを見ることができ、これは私自身のアイデアや考えで、私たちは一緒に勉強します。次は、パフォーマンスについての質問が含まれますので、頻繁にアイデアや方法解決し、ある
2、問題との溶液
メモリの2.1アウト：
プロジェクトが比較的大きい、我々は一定の時間を操作共通しているメモリの問題のうちに報告されます問題。私は最初のプロジェクトは比較的大きく、ほとんどの開発を完了し、明らかにこの方法は非常に時間がかかる場合は、エラーや無限ループがあるコードをすべて見ての、考えて、この問題が発生した、最も直接的かつ効果的な方法は、JVMのメモリを増やすことですサイズは、心配しないで、次のようにパフォーマンスの最適化を改善するために、ステップバイステップになります
ケース1：Tomcatの解凍のバージョン、コンフィギュレーションをロードするためには、startup.batをすることによって、Tomcatを起動することができます
TOMCATはcatalina.batの下にbinを追加するには
ゲスCATALINA_HOME IF REM定義されていない
赤のSET current_dir =％でcd％の追加バックは、新たに追加されています。
セットJAVA_OPTS = -Xms256m -Xmx512m -XX：PermSizeを= 128M -XX：MaxNewSize = 256メートル-XX：MaxPermSizeを= 256メートルます。-Djava.awt.headless =真
ケース2：Tomcatのインストールの次のバージョンはcatalina.batありません
Windowsサービスは、ビン/ tomcat.exeで行った。彼はむしろはcatalina.batの設定よりも、レジストリの値を読み取ります。
修改注册表HKEY_LOCAL_MACHINE / SOFTWARE / Apache Software Foundationの/ Tomcatサービスマネージャー/ tomcat5が/パラメータ/ JavaOptions
原值为-Dcatalina.home = "C：/ ApacheGroup / Tomcatの5.0" -Djava.endorsed.dirs = "C：/ ApacheGroup / Tomcatの5.0 /共通/承認」-Xrs
-Xms300m -Xmx350m参加
Tomcatを再起動サービス、効果取るためにセット
2.2応答時間が長くなる
ストレステストでのプロジェクト、時間の同時テスト、多くの場合、長時間の操作レスポンスがあるでしょう！私たちは、jsが過ぎるなど、インポート、JavaのWebプロジェクトがあまりにも多くのjarパッケージをインポートしたかどうかを検討する
すべてのjarパッケージをコンパイルするためのプロジェクトを開始しますが、バックTomcatの新しいjarファイルパッケージへのプログラムコードが存在しない場合JARパッケージを行うにはほとんど持っているどのくらいの本の、あるコンテンツ、ジャーパッケージが実装されることはありません、
jsのは、瓶より多く詰め込むことが可能であり、同じ理由で、マルチjsが特に重要ではありません
、私はこの問題に対処すると思うので、いくつかのステップ：
1、COLLATE既存のコード、次の図のコードが表示されますがために代わって実行するための導入により、削除、およびコードがクリアされている場合は、このステップでは、あなたがこのjarパッケージといくつかの未使用に従ってを削除することができますしかし、あなたは削除するように注意しなければなりません
4秒以上ならば2は、最初のステップの後に行われ、我々は最も重要なステップを開始し、我々はSQLクエリ時間を必要とし、ページの応答時間、例えば、我々はページの応答時間を指定し、4秒以上にすることはできません、と私たちは行きましたSQLが終了した後、応答時間は外でまだ所定の時間であれば、この操作のコードを見て、見て最初は時間が規定時間を超えた場合に、時間を短縮することができるように、SQLステートメントを変更するには、SQL時間の使用であり、 、その後、主としてそれらのような文ながらループするため、計算方法は、このステップは直接削除することができるようにするためではないいくつかの方法とすることができるように、コードを見て
テストページの第二段階に応じて、私は信じて、3、プロジェクトパフォーマンスは確かに昇格されていたであろう
条件をプロジェクトにサポートしている場合、時間の3段階のテストの間、圧力点を増加させ、同時することができ、より正確なテスト：注意を。
注意：これは、私たちのパフォーマンスの最適化プロセスを強化することである、ない開発プロセス自体を変更することはできませんプロジェクトの論理は、コードの多くは、それが増加することができない場合は、修正することが最善ではありません、のどのような方法です！