Sun ONE ロゴ     前へ      目次      索引      次へ     
Sun ONE Application Server 7 パフォーマンスチューニングガイド



パフォーマンスに関する一般的な問題

ここでは、Web サイトのパフォーマンスに関する次の一般的な問題について説明します。

check-acl サーバーアプリケーション機能

サーバーのパフォーマンスを最適化するには、ACL は必要な場合にだけ使用します。

デフォルトサーバーは、デフォルト ACL を含む ACL ファイルで設定されています。デフォルト ACL では、サーバーへの書き込みアクセスは「all」だけに許可され、es-internal ACL の書き込みアクセスは「anybody」に限定されます。後者によって、サーバーのマニュアル、アイコン、検索 UI ファイルが保護されます。

デフォルトの obj.conf ファイルには、NameTrans という行があります。これは、読み取り専用に設定する必要のあるディレクトリを es-internal オブジェクトにマッピングし、このオブジェクトには es-internal ACL の check-acl SAF が含まれます。

デフォルトオブジェクトには、デフォルト ACL の check-acl SAF も含まれます。

サーバーのパフォーマンスを向上するには、server.xml の仮想サーバータグから aclis プロパティを削除します。これにより、ACL の処理が停止されます。

ACL によって保護されない URI のデフォルトオブジェクトから check-acl SAF を削除して、パフォーマンスを向上することもできます。

低メモリの状況

低メモリの状況で Sun ONE Application Server を実行するには、RqThrottle の値を下げて、スレッドの上限を最小限に抑えます。また、MaxProcs の値を下げて、Sun ONE Application Server が生成するプロセスの最大数を減らすことも有効です。

利用可能スレッドの不足

サーバーでは、スレッド数の上限を超えてアクティブスレッドの数が増えることはありません。同時に処理される要求の数がこの上限に達すると、サーバーは古い接続が解放されるまで新しい接続の処理を停止します。これにより、応答時間が長くなることがあります。

Sun ONE Application Server では、サーバーの RqThrottle のデフォルト値は 128 です。サーバーが同時に処理できる要求の数を増やすときは、RqThrottle の値を増やします。

サーバーで利用できるスレッドが不足している場合、その兆候は応答時間の長さに表れます。ブラウザから要求を送信した場合、通常はサーバーとの接続は迅速に確立されますが、利用可能スレッドが不足しているサーバーでは、クライアントに応答が戻るまでに長い時間が必要となります。

サーバーのスレッド不足を確認する一番の方法は、アクティブセッションの数が RqThrottle によって設定される最大数にどれだけ近づいているかを確認することです。手順については、「最大同時要求数」を参照してください。

キャッシュの未使用

キャッシュが使われないと、サーバーのパフォーマンスを最適化できません。ほとんどのサイトには、常にキャッシュ可能な GIF ファイルや JPEG ファイルが多数含まれているため、キャッシュを効率的に利用する必要があります。

ただし、一部のサイトでは CGI や SHTML などの動的なソースを使ってほとんどの処理を行っています。一般に、動的なコンテンツをキャッシュすることはできません。また、キャッシュの利用率も低くなります。キャッシュの利用率が低くても、過剰な心配は必要ありません。最も重要なことは、応答時間を低く抑えることです。キャッシュの利用率が低くても、良好な応答時間を得ることはできます。応答時間が良好であれば、キャッシュの利用率を気にする必要はありません。

キャッシュの利用率は、perfdump が出力する統計、または Web ベースの管理コンソールの「監視」ページを使って調べることができます。利用率は、キャッシュのルックアップ回数に対するキャッシュのヒット回数の割合を示します。50% 以上であれば、利用率は良好であると言えます。サイトによっては、98% 以上に達することもあります。

CGI や NSAPI の呼び出しが多いサイトでは、キャッシュの利用率が低くなることがあります。カスタム NSAPI 機能を利用している場合も、キャッシュの利用率は低くなります。

キープアライブ接続のフラッシュ

キープアライブ接続なしで 1 秒間に 75 の要求を処理できる Web サイトであれば、キープアライブ接続を有効にすると 1 秒間に 200 〜 300 の要求を処理できます。クライアントは 1 つのページに対しても多数の項目を要求するため、キープアライブ接続を効率的に利用することが重要です。KeepAliveCountMaxKeepAliveConnections を超えると、接続がキープアライブの対象となっており、実際に使われていても、その接続は閉じられます (または「フラッシュ」されます)。

KeepAliveFlushesKeepAliveHits の値は、perfdump が出力する統計、または Web ベースの管理コンソールの「監視」ページを使って調べることができます。キープアライブ接続が効率的に利用されているサイトでは、KeepAliveHits に対する KeepAliveFlushes の割合は低く抑えられています。この比率が 1:1 以上に高くなるときは、サイトでキープアライブ接続を効率的に利用できていない可能性があります。

キープアライブ接続のフラッシュを減らすには、init.conf ファイルを編集するか、Web ベースの管理コンソールを使って MaxKeepAliveConnections の値を増やします。デフォルト値は 200 です。この値を大きくすることで、より多くのキープアライブ接続を待ち状態で開いたまま維持できます。



警告

UNIX または Linux システムでは、MaxKeepAliveConnections の値を大きくしすぎると、サーバーが開いておけるファイル記述子が不足することがあります。UNIX または Linux 環境では、通常、開いておけるファイルの上限は 1024 なので、500 以上の値を設定することはお勧めできません。



ログファイルのモード

ログファイルの設定を詳細モードのままにしておくと、パフォーマンスに大きな影響を生じます。Web ベースの管理コンソールを使うことで、LogVerbose には FINE 以上の任意のレベルを設定できます。


前へ      目次      索引      次へ     
Copyright 2002 Sun Microsystems, Inc. All rights reserved.