方法 1: サーブレットの init() メソッドでデータをキャッシュする
アプリケーション サーバーは、サーブレット インスタンスを初期化した後、クライアントのリクエストを処理する前に、サーブレットの init() メソッドを呼び出します。サーブレットのライフサイクルでは、init() メソッドは 1 回だけ呼び出されます。 init() メソッドで静的データをキャッシュしたり、一度だけ実行するだけで済む時間のかかる操作を完了したりすることで、システムのパフォーマンスを大幅に向上させることができます。
たとえば、init() メソッドでの JDBC 接続プールの確立がその最良の例です。通常の状況では、JNDI ソースを通じて特定のデータを取得するために jdbc2.0 の DataSource インターフェイスを使用するとします。特定のアプリケーションで、SQL リクエストごとに JNDI クエリが実行されると、システムのパフォーマンスが急激に低下することが想像できます。解決策は次のコードです。これは、DataSource をキャッシュして、次の SQL 呼び出し中に引き続き使用できるようにします。
パブリッククラスControllerServletはHttpServletを拡張します
{
プライベート javax.sql.DataSource testDS = null;
public void init(ServletConfig config) は ServletException をスローします
{
super.init(config);
コンテキスト ctx = null;
試す
{
ctx = 新しいInitialContext();
testDS = (javax.sql.DataSource)ctx.lookup("jdbc/testDS";
}
catch(NamingException ne)
{
ne.printStackTrace();
}
catch(例外 e)
{
e.printStackTrace();
}
public javax.sql.DataSource getTestDS(
)
{
testDS を返します。
}
...
...
2
: サーブレットと JSP の自動再ロードを無効にする (自動再ロード)
サーブレット/JSP は、サーブレットや JSP ページを変更するときにアプリケーション サーバーを再起動する必要がなく、開発者に良好な開発環境を提供する自動リロード技術という実用的な技術を提供します。しかし、この技術は、JSP エンジンのクラスローダに多大な負担をもたらすため、製品の実行段階でシステム リソースが大幅に失われます。したがって、自動リロード機能をオフにすることは、システムのパフォーマンスを向上させるのに非常に役立ちます。
方法 3: HttpSession を悪用しない
多くのアプリケーションでは、ページが相互に通信できるように、プログラムはクライアントの状態を維持する必要があります。しかし、残念ながら、HTTP は本質的にステートレスであるため、クライアントの状態を保存できません。そのため、一般的なアプリケーションサーバーはクライアントの状態を保存するためのセッションを提供します。 JSPアプリケーションサーバでは、セッション機能はHttpSessionオブジェクトを通じて実装されていますが、便利な半面、システムへの負担も大きくなります。セッションを取得または更新するたびに、システム オペレーターは時間のかかるシリアル化操作をセッションに対して実行する必要があるためです。次の方法で HttpSession を処理することにより、システムのパフォーマンスを向上させることができます。
必要がない場合は、JSP ページの HttpSession のデフォルト設定をオフにする必要があります。明示的に指定しない場合、各 JSP ページはデフォルトで HttpSession を作成します。 JSP でセッションを使用する必要がない場合は、次の JSP ページ インジケーターを使用してセッションを無効にすることができます。
＜%@ ページセッション="false"%＞
大きなデータ オブジェクトを HttpSession に保存しない: 大きなデータ オブジェクトを HttpSession に保存すると、アプリケーション サーバーは読み取りまたは書き込みのたびにデータ オブジェクトをシリアル化するため、システムに余分な負担がかかります。 HttpSession に保存するデータ オブジェクトが大きくなるほど、システム パフォーマンスの低下が早くなります。
HttpSession が必要なくなったら、できるだけ早く解放します。セッションが必要なくなったら、HttpSession.invalidate() メソッドを呼び出して解放できます。
セッション タイムアウトをできるだけ短く設定してください。JSP アプリケーション サーバーには、デフォルトのセッション タイムアウトがあります。この時間が経過しても顧客が操作を実行しない場合、システムは関連するセッションをメモリから自動的に解放します。タイムアウトを大きく設定すると、システムのパフォーマンスが低下するため、その値をできるだけ低く保つことが最善の方法です。
方法 4: ページ出力を圧縮する
圧縮は、特にネットワーク帯域幅が十分に開発されていない今日において、データの冗長性を解決する良い方法です。一部のブラウザは、HTML ファイルの圧縮に gzip (GNU zip) をサポートしています。この方法を使用すると、HTML ファイルのダウンロード時間を大幅に短縮できます。したがって、サーブレットや JSP ページによって生成された HTML ページを圧縮すると、ユーザーはページの閲覧速度が非常に速く感じるようになります。残念ながら、すべてのブラウザが gzip 圧縮をサポートしているわけではありませんが、クライアントのブラウザが gzip 圧縮をサポートしているかどうかをプログラムで確認できます。このメソッドがどのように実装されるかを示すコード スニペットを次に示します。
public void doGet(HttpServletRequest リクエスト、HttpServletResponse レスポンス)
IOException、ServletExceptionをスローします
{
出力ストリーム出力 = null
文字列エンコーディング = request.getHeader("Accept-Encoding";
if (エンコーディング != null && エンコーディング.indexOf("gzip" != -1)
{
request.setHeader("コンテンツエンコーディング" , "gzip";
out = 新しい GZIPOutputStream(request.getOutputStream());
}
else if (エンコーディング != null && エンコーディング.indexOf("comdivss" != -1)
{
request.setHeader("コンテンツエンコーディング" , "comdivss";
out = 新しい ZIPOutputStream(request.getOutputStream());
}
それ以外
{
out = request.getOutputStream();
}
...
...
方法 5: スレッド プールを使用します。
アプリケーション
サーバーは、デフォルトでそれぞれの異なるクライアント要求を処理するためのスレッドを作成し、service() メソッドの呼び出しが完了すると、対応するスレッドもキャンセルします。 。スレッドの作成と破棄は特定のシステム リソースを消費するため、このデフォルト モードではシステム パフォーマンスが低下します。しかし幸いなことに、スレッド プールを作成することでこの状況を変えることができます。さらに、このスレッド プールの最小スレッド数と最大スレッド数も設定する必要があります。アプリケーション サーバーは起動時に、最小スレッド数と同じ数のスレッド プールを作成します。顧客からのリクエストがあると、処理のためにスレッドがプールから取り出され、処理が完了します。真ん中のプールに戻します。プール内に十分なスレッドがない場合、システムはプール内のスレッド数を自動的に増やしますが、合計数がスレッドの最大数を超えることはできません。スレッドプールを使用することで、クライアントリクエストが急増した場合でもシステム負荷が滑らかな上昇曲線を描くようになり、システムのスケーラビリティが向上します。
方法 6: 適切なページ組み込みメカニズムを選択する
JSP に別のページをインクルードするには 2 つの方法があります。 1. インクルード インジケーター (<%@ includee file="test.jsp" %>) を使用します。 2. JSP インジケーター (<jsp:includee page="test.jsp" flash="true"/>) を使用します。実際に、最初の方法を使用すると、システムのパフォーマンスが向上することがわかりました。
方法 7: JavaBeans のライフサイクルを正しく決定する
JSP の強力な機能の 1 つは、Javabean のサポートです。 JSP ページで <jsp:useBean> タグを使用すると、Javabean を JSP ページに直接挿入できます。使用方法は次のとおりです。
＜jsp:useBean id="name"scope="page|request|session|application" class=
"package.className" type="typeName">
＜/jsp:useBean＞
scope 属性は、この Bean のライフサイクルを示します。デフォルトのライフサイクルはページです。 Bean のライフサイクルを正しく選択しないと、システムのパフォーマンスに影響します。
たとえば、特定の Bean を 1 つのリクエストでのみ使用したいが、Bean のライフサイクルをセッションに設定した場合、リクエストが終了しても、セッション タイムアウトになるかユーザーがブラウザを閉じない限り、Bean はメモリ内に残ります。これにより、一定量のメモリが消費され、JVM ガベージ コレクターのワークロードが不必要に増加します。したがって、Bean の正しいライフサイクルを設定し、ミッション終了後にできるだけ早くクリーンアップすると、システムのパフォーマンスが向上します。
他の方法
文字列の連結操作では「+」演算子を使用しないようにしてください。Java プログラミングでは、複数の文字列を接続するために「+」演算子をよく使用しますが、それが実際にシステムのパフォーマンスに影響を与えるとは考えてもいなかったかもしれません。文字列は定数であるため、JVM はいくつかの一時オブジェクトを生成します。 「+」を多く使用すると、より多くの一時オブジェクトが生成され、システムのパフォーマンスにも影響します。解決策は、「+」演算子の代わりに StringBuffer オブジェクトを使用することです。
System.out.println() メソッドの使用を避ける: System.out.println() は同期呼び出しであるため、つまり呼び出し時には、ディスク I/O 操作はその完了を待つ必要があるため、回避するように努める必要があります。それを使って電話する。しかし、この矛盾を解決するには、System.out.println() メソッドを生成せずにデバッグを容易にする Log4j ツールを使用することをお勧めします。
ServletOutputStream と PrintWriter の間のトレードオフ: PrintWriter を使用すると、若干のオーバーヘッドが生じる可能性があります。これは、PrintWriter がすべての生出力を出力用の文字ストリームに変換するためです。そのため、ページ出力として使用する場合、システムは変換プロセスを実行する必要があります。ページ出力としてServletOutputStreamを使用しても問題ありませんが、バイナリで出力されます。したがって、実際のアプリケーションでは、両方の長所と短所を比較検討する必要があります。
要約する
この記事の目的は、サーブレットと JSP のチューニング手法を通じてアプリケーションのパフォーマンスを大幅に向上させ、それによって J2EE アプリケーション全体のパフォーマンスを向上させることです。これらのチューニング手法を通じて、アプリケーションのパフォーマンスを決定するのは特定の技術プラットフォーム (J2EE と .NET の間の論争など) ではないことがわかります。重要なのは、このプラットフォームをより深く理解することです。そうすることでのみ、アプリケーションを根本的に最適化することができます。