IBM WebSphere Portal 7.0 IBM コラボレーション・ソリューション・パフォーマンス・チーム 2010 年 12 月

IBM WebSphere Portal ソフトウェア・ファミリー
お客様の世界。お客様の方法。
IBM WebSphere Portal 7.0
パフォーマンス・チューニング・ガイド
IBM コラボレーション・ソリューション・パフォーマンス・チーム
2010 年 12 月
ドキュメント・バージョン 1
目次
パフォーマンス・チューニングの概要.………………………………………………..…..…….. 1
環境考察事項.……………………………………………………………………………...……….. 2
32 ビット/64 ビットの検討……………………………………………………….…….2
ハードウェア・マルチスレッド化 (ハイパースレッド化) …………………………... 4
ポータルのトポロジー……………………………………………………………….…. 4
ベース・ポータルのチューニング……………………………………………………………….... 8
アプリケーション・サーバーのチューニング……………………………………………….... 9
JVM の初期および最大ヒープ・サイズ……………………………………………….. 9
JVM ヒープの大容量ページ………………………………………………………….. 11
JVM ヒープの新しい領域のサイズ………………………………………………...... 17
共有クラスのキャッシュ・サイズ………………………………………………......... 17
追加の JVM 引数………………………………………………................................. 20
追加の SUN JVM 引数……………………………………………………………….... 20
追加の Z/OS JVM 引数………………………………………………........................ 21
Z/OS での JVM ヒープ圧縮リファレンス・オプション…………………………... 22
JDK の修正………………………………………………........................................... 24
セッション・タイムアウト……………………………………………….................... 24
Web コンテナー・スレッド・プールのサイズ………………………………………. 26
データ・ソースのチューニング……………………………………………..……….... 26
セキュリティー属性伝搬………………………………………………...................... 29
Internationalization Service のチューニング…………………………………………. 30
タグ付けと格付けの無効化……………………………………………….................. 31
フレンドリー URL の無効化………………………………………………............... 31
LTPA のチューニング……………………………………………….......................... 33
テーマのベース URL の有効化………………………………………………............ 33
検索の無効化………………………………………………........................................ 35
VMM のチューニング………………………………………………........................... 36
Z/OS の ORB サービスのチューニング……………………………………………. 38
WebSphere Portal Service…………………………………………………………………..... 39
ナビゲーター・サービス………………………………………………………..…….... 40
レジストリー・サービス…………………………………………………………..….... 41
キャッシュ・マネージャー・サービス……………………………………………….... 42
データベースのチューニング…………………………………………………………….... 46
DB2 データベース・サーバーのチューニング………………………………………. 46
ORACLE データベース・サーバーのチューニング……………………………….... 52
ii
WEBSPHERE PORTAL 7.0 TUNING GUIDE
データベースに関するその他の考慮事項………………………………………..….. 56
ディレクトリー・サーバーのチューニング…………..………………………………….... 58
Web サーバーのチューニング………………………………………………………...….... 60
プラグインのチューニング……………………………………………………………….... 62
オペレーティング・システムのチューニング………………………………………….... 62
AIX…………………………………………………………………………………..….... 62
Linux…………………………………………………………………………………....... 64
Windows 2003………………………………………………......................................... 66
Solaris………………………………………………................................................... 66
Z/OS………………………………………………..................................................... 72
ページ・ビルダー・テーマのチューニング……………………............................................... 75
CacheManagerService プロパティー……………………................................................ 75
Internet Explorer でブラウザー・キャッシュが適切に機能していることの確認......................... 76
リダイレクトの削減……………................................................................................... 77
WebDAV リソースの提供……………........................................................................... 78
サーバー・サイド・モードでのマッシュアップ・マルチパート・チューニング……………....... 79
ページおよびポートレットでのパーソナライゼーション可視性ルールの無効化…………...... 80
キャッシング・プロキシーの使用……………............................................................... 80
Web サーバーのチューニング…………….................................................................... 86
大量ページのチューニング………....................................................................................... 88
DB2 データベースのチューニング……….................................................................... 88
キャッシュ・マネージャー・サービス............................................................................ 89
Web コンテンツ管理のチューニング.................................................................................. 90
アプリケーション・サーバーのチューニング…............................................................ 90
WebSphere Portal サービスのプロパティー................................................................. 91
キャッシュ・マネージャー・サービス..................................................................... 91
アクセス制御データ管理サービス........................................................................ 92
ナビゲーション・サービス..................................................................................... 92
パーソナライゼーション・サービス....................................................................... 93
WCM オブジェクト・キャッシュ................................................................................... 94
WCM 構成サービス...................................................................................................... 94
Web コンテンツ・ビューアー・ポートレットのキャッシュ........................................... 96
JCR テキスト検索...................................................................................................... 100
DB2 のチューニング (オーサリング環境) ................................................................. 100
マルチプラットフォーム (LUW) ......................................................................... 100
Z/OS.................................................................................................................... 102
iii
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Oracle のチューニング (レンダリングおよびオーサリング) .................................... 107
クラスターのチューニング................................................................................................ 108
アプリケーション・サーバーのチューニング.............................................................. 108
Dynacache カスタム・プロパティー.................................................................... 108
動的キャッシュ複製............................................................................................ 109
VMM コンテキスト・プール................................................................................. 109
メモリー間のセッション・パーシスタンスのチューニング........................................ 109
JVM ヒープ......................................................................................................... 111
セッション・パーシスタンスのチューニング...................................................... 111
WAS フィックスパック....................................................................................... 113
AIX ネットワーク................................................................................................ 113
プラグイン........................................................................................................... 113
データベースに対するセッション・パーシスタンスのチューニング.......................... 113
垂直クラスターのチューニング................................................................................. 116
その他のパフォーマンス・チューニング・オプション........................................................ 117
ネスト・グループ・キャッシュ..................................................................................... 117
ユーザーの最終ログイン時刻の記録.......................................................................... 118
アクセス制御におけるアクセス権の取得の最適化..................................................... 119
ポータルの起動パフォーマンスの改善....................................................................... 122
WebSphere Portal 開発モード.............................................................................. 122
WebSphere Portal ライト・モード......................................................................... 123
ユーザー属性の取得の管理......................................................................................... 124
ユーザー属性のフルフェッチの特定................................................................... 126
最小属性セット................................................................................................... 127
動的コンテンツ機能の使用........................................................................................ 127
パーソナライゼーションのベスト・プラクティス...................................................... 128
HTTP サーバーでコンテンツを圧縮する。.......................................................... 129
クライアント・サイド・キャッシュの有効化........................................................ 131
ポートレット・キャッシュ.......................................................................................... 132
ログイン・ページをキャッシュ可能にする設定................................................... 133
WebSphere Portal キャッシュ............................................................................................ 134
一般情報..................................................................................................................... 134
キャッシュ構成プロパティー.............................................................................. 134
キャッシュの使用パターン......................................................................................... 137
キャッシュ・インスタンス.......................................................................................... 140
アクセス制御....................................................................................................... 140
iv
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ポータル・ユーザー管理....................................................................................... 151
データストア....................................................................................................... 152
モデル.................................................................................................................. 156
URL マッピング.................................................................................................. 164
仮想ポータル....................................................................................................... 165
WSRP................................................................................................................... 167
動的アセンブリー / プロセス統合..................................................................... 171
ポリシー.............................................................................................................. 172
コラボレーション・サービス................................................................................ 173
その他.................................................................................................................. 176
シナリオ例.................................................................................................................. 179
一般的なコメント................................................................................................ 179
ページ数が少なく、ユーザー数が少ない場合...................................................... 181
ページ数が少なく、ユーザー数が多い場合.......................................................... 181
長いセッション・タイムアウトのあるポータル................................................... 183
ページ数が多いあるポータル.............................................................................. 183
Web Content Management キャッシュ................................................................................ 185
WCM キャッシュ・インスタンス................................................................................. 185
WCM 項目キャッシュ.......................................................................................... 185
WCM サマリー..................................................................................................... 186
WCM 基本キャッシュ.......................................................................................... 186
拡張およびリソース............................................................................................ 186
セッション・キャッシュ....................................................................................... 188
メニュー.............................................................................................................. 188
ナビゲーター....................................................................................................... 188
絶対パス.............................................................................................................. 188
消失項目.............................................................................................................. 190
ライブラリー....................................................................................................... 190
ライブラリー親................................................................................................... 190
ドラフト・サマリー.............................................................................................. 190
ユーザー・キャッシュ.......................................................................................... 191
付録 A 参照....................................................................................................................... 193
付録 B クレジット............................................................................................................ 195
v
WEBSPHERE PORTAL 7.0 TUNING GUIDE
図
図 1 ポートレット設定のスクリーン・ショット................................................................. 96
図 2 ポータルのアクセス制御キャッシュの階層.............................................................. 142
図 3 ポータル・モデルのキャッシュの階層....................................................................... 156
表
表 1: 追加の Sun JVM 設定................................................................................................ 20
表 2: データベース・ドメイン............................................................................................. 27
表 3: WebSphere セキュリティー属性伝搬の設定............................................................... 30
表 4: タグ付けと格付けの設定........................................................................................... 31
表 5: フレンドリー URL の設定......................................................................................... 32
表 6: WebSphere Security LPTA2 の設定.............................................................................. 33
表 7: VMM コンテキスト・プールの設定.............................................................................. 37
表 8: VMM キャッシュの設定.............................................................................................. 37
表 9: ナビゲーション・サービスの設定............................................................................... 41
表 10: レジストリー・サービスの設定................................................................................. 42
表 11: キャッシュ・マネージャー・サービスの設定............................................................. 44
表 12: Oracle データベースのチューニング........................................................................ 56
表 13: IDS のチューニング.................................................................................................. 58
表 14: Web サーバーのチューニング.................................................................................. 60
表 15: AIX のネットワーク設定........................................................................................... 63
表 16: Linux のネットワーク設定........................................................................................ 64
表 17: Windows のネットワーク設定................................................................................... 66
表 18: Solaris のネットワーク設定...................................................................................... 66
表 19: z/OS システムのチューニング................................................................................. 74
表 20: デフォルトの Portal 7 ページ・ビルダー・テーマ用の CacheManager サービス設定......................... 76
表 21: マッシュアップ・マルチパート・モード設定............................................................. 80
表 22: HTTP キャッシュ用の HTTP サーバー設定............................................................ 84
表 23: リバース・プロキシー設定........................................................................................ 86
表 24: 大量ページ用の DB2 データベース設定................................................................. 88
表 25: 大量ページ用のキャッシュ・マネージャー・サービス設定....................................... 89
表 26: WCM 用のキャッシュ・マネージャー・サービス設定................................................. 91
表 27: WCM 用のアクセス制御データ管理サービス設定.................................................... 92
表 28: WCM 用のナビゲーション・サービス設定................................................................. 92
表 29: WCM 複合レンダリング用のパーソナライゼーション・サービス設定...................... 94
vi
WEBSPHERE PORTAL 7.0 TUNING GUIDE
表 30: WCM オブジェクト・キャッシュ設定........................................................................ 94
表 31: DB2 z/OS バッファー・プール設定......................................................................... 103
表 32: WebSphere メモリー間セッション・パーシスタンスのチューニング..................... 111
表 33: WebSphere セッション・パーシスタンスのチューニング....................................... 114
vii
WEBSPHERE PORTAL 7.0 TUNING GUIDE
本書について
このホワイト・ペーパーでは、IBM WebSphere Portal for Multiplatform for Linux on System Z、
および IBM WebSphere Portal for Multiplatform z/OS V7.0 のパラメーターおよびアプリケー
ション・チューニングの基礎を説明します。チューニングとキャパシティーは、いずれも
ワークロード・シナリオやパフォーマンス測定環境など、多くの要素から影響を受けるこ
とを忘れないでください。チューニングについての本書の目的は、IBM がそのシナリオを
測定したときに使用した値を使用するようにお客様に勧めるのではなく、IBM の構成に使
用したパラメーターを認識してもらうことです。お客様の個々のシステムをチューニング
するときに重要なことは、ベースラインから始めること、パフォーマンス・メトリックを
モニターしていずれかのパラメーターを変更する必要があるかどうかを判断すること、お
よび変更した場合に、パフォーマンス・メトリックをモニターして変更が有効であったか
どうかを判断することです。
パフォーマンス・チューニングの概要
WebSphere Portal 環境のチューニングには、環境のさまざまなシステムとコンポーネント
のチューニングと構成が含まれます。本章ではいくつかの一般的な概念について検討し、
IBM の測定環境に使用した構成のみに当てはまる事柄について詳述します。そのような事
柄によって以下が必要になります。
•
アプリケーション・サーバーと、アプリケーション・サーバー用に定義されたリソー
スの構成
•
データベースとデータベース・サーバーのチューニング
•
ディレクトリー・サーバーとそのデータベースのチューニング
•
Web サーバーおよび/またはプロキシー・サーバーのチューニング
•
オペレーティング・システムとネットワークのチューニング
•
WebSphere Portal サービスのチューニング
お客様の個々のシステムをチューニングするときに重要なことは、ベースラインから始め
ること、パフォーマンス・メトリックをモニターしていずれかのパラメーターを変更する
必要があるかどうかを判断すること、および変更した場合に、パフォーマンス・メトリッ
クをモニターして変更が有効であったかどうかを判断することです。
1
WEBSPHERE PORTAL 7.0 TUNING GUIDE
IBM がその測定環境で変更したチューニングの他にも、特定の状況でパフォーマンスを向
上させることができるいくつかのチューニング・オプションが利用可能です。それらにつ
いては別のセクションで検討します。
環境考察事項
WebSphere Portal のインストールを始める前に、環境をどのように使用して理想的なパフ
ォーマンスを達成しようとしているかを検討する必要があります。検討すべきトピックは
以下のとおりです。
•
JVM の選択 (32 ビットまたは 64 ビット)
•
ハードウェア・マルチスレッド化 (同時マルチスレッド化、ハイパースレッド化とも呼
ばれる) の使用
•
ユーザーおよびシステム負荷をサポートするためのサーバー・トポロジーの選択
32 ビット/64 ビットの検討
32 ビットまたは 64 ビット JVM の選択にはいくつかのトレードオフがあります。64 ビッ
ト JVM の主な利点は、アドレス・スペースがはるかに大きいことです。最新のサーバー・
システムでは、2.5GB 以上のヒープ・サイズが実用的な場合があります。これは、多くの
メモリーを必要とするアプリケーションにとって著しく大きな利点である場合があります。
64 ビット JVM には欠点もあります。それは、64 ビット JVM のマシン命令とメモリー参
照が 32 ビット JVM のものより大きいことです。これは、一般に複数のメモリー参照を含
む Java オブジェクトが、32 ビット JVM より 64 ビット JVM の場合に大きくなること
を意味します。したがって、オブジェクト数が同じであれば、64 ビット JVM は 32 ビッ
ト JVM より大きなヒープを必要とします。
命令とメモリー参照のサイズが増えると、パフォーマンス上で不利な点がもう 1 つ生まれ
ます。それは、システムのメモリー・サブシステムへの要求が増えるためにキャッシュ・
ミスが増え、さらに多くのメモリー帯域幅が要求されることです。その結果、64 ビット JVM
での一連の命令の実行が、32 ビット JVM での同じ命令の実行より遅くなる場合がありま
す。
2
WEBSPHERE PORTAL 7.0 TUNING GUIDE
WebSphere Portal 7.0 のデプロイメントを検討するときは、アプリケーションが要求するメ
モリーを考慮してください。メモリー要求が多いと予想されるのであれば、最良のパフォ
ーマンスはおそらく 64 ビット JVM から得られるでしょう。一方、メモリー要求が少ない
なら、32 ビット JVM の方が優れたパフォーマンスをもたらすと考えられます。いくつか
の新しいハードウェア、例えば Power6 を実行する AIX 64 ビット JVM では、64 ビット
JVM の方が 32 ビット JVM よりも優れたパフォーマンスを実現しました。64 ビット
JVM にするか 32 ビット JVM にするかを検討するときには、このことを考慮に入れてく
ださい。
3
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ハードウェア・マルチスレッド化 (ハイパースレッド化)
最新のプロセッサー・アーキテクチャーの多くが、ハードウェア・マルチスレッド化をサ
ポートしています。例えば、インテル・プロセッサーではハイパースレッド化 (HT)、Power
シリーズ・プロセッサーでは同時マルチスレッド化 (SMT) と呼ばれるものがそうです。IBM
の経験では、ハードウェア・マルチスレッド化を使用すると、測定したすべてのシナリオ
やプラットフォームでキャパシティーが向上したため、ハードウェア・マルチスレッド化
をオプションとして採用しているプラットフォームでは必ず使用することをお勧めします。
ポータルのトポロジー
WebSphere Portal は、さまざまなデプロイメント・トポロジーをサポートしています。代
表的なデプロイメントには 3 層構造を使用します。
•
HTTP サーバー
•
アプリケーション・サーバー
•
データベース・サーバーおよびディレクトリー・サーバー
多層構造を持つことの主な利点は、複数のデータベースとアプリケーションが 1 つのサー
バーに常駐することによって発生するリソース競合がなくなることです。データベース・
サーバーとアプリケーション・サーバーがノードを共有すると、共用リソースが競合して
達成可能なスループットの大きさにマイナスの影響を与えます。一方、小規模なデプロイ
メントでは、このようなサーバーのいくつかを単一ノードにデプロイできるほどわずかな
リソースしか必要としない可能性があります。
シングル・サーバー・トポロジー
小規模なデプロイメントでは、これらの層のいくつかが単一システムで実行される可能性
があります。例えば、小さな環境での一般的な構成では、HTTP サーバーとアプリケーショ
ン・サーバーの実行に単一ノードを使用する一方、データベース・サーバーとディレクト
リー・サーバーは依然として別のシステムに配置します。これは、IBM がシングル・サー
バー構成に使用した構成です。
クラスター・トポロジー
クラスター・デプロイメントでは、それぞれの層に 1 つ以上のノードを配置します。IBM が
4
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ラボで使用したクラスター構成を以下に示します。
第 1 層は Web サーバーです。
ロード・バランシングには WebSphere プラグインを使用しました。入力されたクライアン
トからの http 要求は、プラグインがデフォルトの「ラウンドロビン」ロード・バランシン
グ・アルゴリズムを使用して、ポータル・サーバーのクラスターにルーティングします。
5
WEBSPHERE PORTAL 7.0 TUNING GUIDE
多くのクラスター・デプロイメントでは、ロード・バランサーがそのようなサーバーにト
ラフィックを向けるマルチ HTTP サーバー構成を使用します。そのため、HTTP サーバー
にキャパシティーが追加されるとともに、HTTP サーバー層でのサーバー・フェイルオーバ
ーがサポートされます。
第 2 層は、ポータル・サーバーとデプロイメント・マネージャーからなります。ポータル・
サーバーは、ポートレットやその他のアプリケーション・ロジックを実行してクライアン
ト要求を処理します。デプロイメント・マネージャーは、それぞれのノードで実行される
ノード・エージェント・プロセスによって、すべてのポータル・サーバー・プロセスを調
整します。
Web サーバー (第 1 層) から入力された http 要求は、WebSphere プラグインを使用して
3 つのポータル・サーバー・ノードの 1 つにルーティングされました。プラグインは、セ
ッション・アフィニティーによって、特定のセッションに関連するすべての要求を同じノ
ードにルーティングしようと試みます。
第 3 層は、すべてのデータベース (LDAP およびポータル・データベース) を含んでいま
した。これらのサーバーは、クラスター内のポータル・サーバーから要求を受信しました。
以下の図は、IBM がラボで使用した LUW 用 3 層クラスター・トポロジーを表しています。
図 1: LUW 用ポータル・クラスターのトポロジー
6
WEBSPHERE PORTAL 7.0 TUNING GUIDE
以下の図は、IBM がラボで使用した System z 用 2 層クラスター・トポロジーを表してい
ます。
図 1: System z 用ポータル・クラスターのトポロジー
7
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ベース・ポータルのチューニング
ベース・ポータルのシナリオは、ユーザー・ログイン、ページ・ナビゲーション、および
簡単なポートレットとの相互作用に対応します。ユーザーは、グループ・メンバーシップ
に基づいて他のユーザーにアクセスし、ページの小さなセットを見ることができますが、
その一部はすべての認証済みユーザーからも見えます。
IBM はその他にも多くのシナリオをベンチマークしましたが、それらはさまざまな機能に
焦点を合わせるか、または WebSphere Portal のユースケースを使用したものです。例えば、
Web コンテンツ・マネジメント (WCM) を利用したシナリオや、ユーザーが数千ページに
アクセスするシナリオがあります。IBM は、異なるチューニングを使用してそれらのシナ
リオのいくつかのパフォーマンスを最適化しましたが、どのチューニングもベース・ポー
タル・シナリオで行ったチューニングに基づいています。本セクションで扱うチューニン
グは、ポータルのすべてのテーマに適用されます。Portal 7 のデフォルト・ページ・ビルダ
ー・テーマに対する追加チューニングは、ページ・ビルダーのチューニング・セクション
にあります。
IBM は、どの測定環境でも、WebSphere Portal サーバーの他に別のデータベース・サーバ
ーとディレクトリー・サーバーを使用します。IBM は、これらのサーバーを別々のシステ
ムで実行して WebSphere Portal サーバーを実行しているシステムでのリソース競合をなく
します。これは、達成可能な最大キャパシティーを向上させるのに役立ちます。
8
WEBSPHERE PORTAL 7.0 TUNING GUIDE
アプリケーション・サーバーのチューニング
WebSphere Application Server には、アプリケーション・サーバーを構成してチューニング
する多くの局面があります。IBM は、ここに示された局面こそ、ラボ環境で WebSphere
Portal が正しく機能して最適実行するのに重要であることがわかりました。
WebSphere アプリケーション・サーバーのチューニングに関する詳細は、以下にあるイン
フォメーション・センターのチューニング・セクションをご覧ください。
http://www-01.ibm.com/software/webservers/appserv/was/library/
管理者コンソールへのアクセス方法
WebSphere の管理コンソールにアクセスするには、2 つの方法があります。
•
Server1 を始動してポート 10001 を使用します。
1. <WAS_root>/profiles/wp_profile/bin 内で
2. ./startServer.sh server1
3. http://yourhost:10001/admin
•
Portal を始動してポート 10027 を使用します。
1. <WAS_Root>/profile/wp_profile/bin 内で
2. ./startServer.sh WebSphere_Portal
3. http://yourhost:10027/ibm/console
上記の (10001 と 10027) は IBM のラボにデプロイしたポート番号ですが、その他のデプ
ロイメントでは別のポートを使用する可能性があります。ご使用のシステムが使用してい
る
ポ
ー
ト
を
知
る
に
は
、
<wp_profile
root>/config/cells/<cell_name>/
nodes/<node_name>/serverindex.xml で「adminhost」を探します。
以下は、上述したベース・ポータルのワークロードでの IBM の経験に基づく設定です。
JVM の初期および最大ヒープ・サイズ
Java VM ヒープ・サイズ: JVM ヒープ・サイズの値は、システムの物理メモリー量に直接
関連します。JVM ヒープ・サイズには、システムの物理メモリーより大きな値を設定しな
9
WEBSPHERE PORTAL 7.0 TUNING GUIDE
いでください。
設定方法: WebSphere 管理コンソールで:「サーバー (Servers)」→「アプリケーション・サ
ーバー (Application Servers)」→「WebSphere Portal」→「Server インフラストラクチャー
(Server Infrastructure)」で: ｢Java およびプロセス管理 (Java and Process Management)｣→「プ
ロセス定義 (Process Definition)」→「Java 仮想マシン (Java Virtual Machine)」
- 初期ヒープ・サイズ
- 最大ヒープ・サイズ
詳細は、JVM 最大ヒープ・サイズの制限をご覧ください。
10
WEBSPHERE PORTAL 7.0 TUNING GUIDE
管理者コンソールへのアクセス方法に関する説明をご覧ください。
JVM 最大ヒープ・サイズの制限
アプリケーション・サーバーのヒープ・サイズを設定するときは、以下の点に気をつけて
ください。
•
すべてのプロセスとオペレーティング・システムを収容するのに十分な物理メモリー
がシステムにあることを確認してください。システムの物理メモリーより多くのメモ
リーが割り当てられると、ページングが発生してパフォーマンスがきわめて低下する
場合があります。
•
IBM は、最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定しました。なぜな
ら、1.5 IBM JDK から使用可能になった、ヒープのフラグメント化を避けるのに役立つ
世代間同時 (「gencon」) ガーベッジ・コレクション・ポリシーを使用しているためで
す。
•
ヒープ・サイズをチューニングした後は、いつでもシステムをモニターしてページン
グが発生していないことを確認します。上述したように、ページングはパフォーマン
スを低下させることがあります。 32 ビットのオペレーティング・システムには、シ
ステムの物理メモリー量にかかわらず 4GB というアドレス・スペースの制限がありま
す。このスペースによって、システムの個々のプロセスの最大サイズが制限されます。
その上、いくつかのオペレーティング・システムはプロセスのサイズをこの限界より
さらに小さな値に制限します。Windows の多くのバージョンはプロセス・サイズを 2GB
に制限します。詳細は http://support.microsoft.com/default.aspx?scid=kb;en-us;555223
をご覧ください。アドレス・スペースの制限によって JVM プロセスのサイズがさらに
限定されます。プロセスが大きくなってオペレーティング・システムによる制限を超
えると、突然終了する場合があります。
•
ヒープ・サイズをチューニングした後は、いつでも詳細ガーベッジ・コレクション出
力をモニターして、選択したヒープ・サイズが適切であるかどうかを判断してくださ
い。理想的には、システムがガーベッジ・コレクションに費やす時間を 5 ～ 10% 以
下に抑える必要があります。z/OS システムでは、Servant Region とともに制御領域も
必ずモニターしてください。詳細ガーベッジ・コレクションの出力を理解するには、IBM
WebSphere Portal パフォーマンス・トラブルシューティング・ガイドのメモリー分析
を参照してください。
WebSphere Portal V7.0 とその基礎コンポーネントが要求するネイティブ・メモリー量を考
慮して、IBM は Windows 環境での最大ヒープ・サイズとして 1408MB を選択しました。
11
WEBSPHERE PORTAL 7.0 TUNING GUIDE
いずれも 32 ビット Windows での 2GB という制限に収めなければならない JVM ヒープ
とネイティブ・メモリーの間にはバランスがあります。1408MB は、Windows 構成とワーク
ロードのすべてを測定するのに使用して成功した最大値でした。お客様のアプリケーショ
ンが追加ネイティブ・メモリーを必要とする場合は、最大ヒープ・サイズを小さくしなけ
ればならないことがあります。詳細は、WebSphere Application Server インフォメーション・
センターをご覧ください。
12
WEBSPHERE PORTAL 7.0 TUNING GUIDE
パラメーター
AIX
Linux
Solaris
Windows
z/Linux
z/OS
N/M
未サポー
2003
初期およ
32 ビ ッ
び最大ヒ
ト
ープ・サイ
64 ビ ッ
ズ (MB)
ト
1792
2048
N/M
1408
ト
3072
N/M
3584
2560
4096
2048
Note:N/M は「測定していない」ことを表します。
JVM ヒープの大容量ページ
大容量ページによって、ヒープを追跡し続けるために必要な CPU オーバーヘッドを減らす
ことができます。測定の結果、大容量ページを設定することで、スループットが 10％ 向
上することが確認されています。
ただし、この設定により Windows のパフォーマンスが向上するのは確かとはいえ、実際に
設定して何かを測定するということはありませんでした。–Xlp が設定されていると Portal
が安定して起動せず、jvm の始動または再始動の前にシステムのリブートが必要となること
があるためです。
設定方法:WebSphere の管理コンソールから、
「サーバー (Servers)」→「アプリケーション・
サーバー (Application Servers)」→「WebSphere Portal」→ サーバー・インフラストラクチ
ャー(Server Infrastructure): 「Java およびプロセス管理 (Java and Process Management)」→
「プロセス定義 (Process Definition)」→「Java 仮想マシン (Java Virtual Machine)」→「汎
用 JVM 引数 (Generic JVM Argument)」にナビゲートします。–Xlp を追加します。
大容量ページは Linux カーネル V2.6 以上を実行するシステムでサポートされています。
「AIX オペレーティング・システムでの JVM 大容量ページの調整」を参照してください。
AIX オペレーティング・システムでの JVM 大容量ページの調整
JVM 大容量ページを使用するには、大容量ページをサポートするように AIX オペレーティ
ング・システムを構成する必要があります。
設定方法:
13
WEBSPHERE PORTAL 7.0 TUNING GUIDE
1. 大容量ページ (16MB) として 4GB の RAM を割り当てる場合は、以下の手順を使用し
ています。このメモリー量はこれらのシステムに 8GB の物理メモリーがあることに基づい
て選択しました。物理メモリーの量が異なるシステムについては、これらの値の調整が必
要となる場合があります。
vmo -r -o lgpg_regions=256 -o lgpg_size=16777216
bosboot -ad /dev/ipldevice
reboot -q
vmo -p -o v_pinshm=1
chuser capabilities=CAP_BYPASS_RAC_VMM,CAP_PROPAGATE $USER
2. 上記のとおり –Xlp コマンド・ライン・オプションを追加します。
3. WebSphere の管理コンソールから、「サーバー (Servers)」→「アプリケーション・サー
バー (Application Servers)」→「WebSphere Portal」→サーバー・インフラストラクチャー
(Server Infrastructure): 「Java およびプロセス管理 (Java and Process Management)」→「プ
ロセス定義 (Process Definition)」→
14
WEBSPHERE PORTAL 7.0 TUNING GUIDE
「環境エントリー (Environment Entries)」→「新規 (New)」→「EXTSHM=OFF」(注: EXTSHM
がオンのとき、大容量ページは使用できません) にナビゲートします。
4. Portal サーバーを再始動します。大容量ページが使用されているかどうかを検証するに
は、AIX コマンド vmstat -l 1 5 を実行して、使用されるアクティブな大容量ページである
alp 列を確認します。大容量ページが使用されている場合、この列はゼロ以外の値になりま
す。
ZLINUX オペレーティング・システムでの JVM 大容量ページの調整
JVM 大容量ページを使用するには、大容量ページをサポートするように zLinux オペレー
ティング・システムを構成する必要があります。
設定方法:
1. デフォルトの大容量ページ・サイズである 2MB を使用する大容量ページとして 6GB の
RAM を割り当てる場合は、以下の手順を使用します。この量はこのシステムので 16GB の
物理メモリーを使用できることに基づいて選択しました。物理メモリーの量が異なるシス
テムについては、これらの値の調整が必要となる場合があります。
2. 上記のとおり –Xlp コマンド・ライン・オプションを追加します。
3. WebSphere の管理コンソールから: 「サーバー (Servers)」→「アプリケーション・サー
バー (Application Servers)」→「WebSphere Portal」→ サーバー・インフラストラクチャー
(Server Infrastructure): 「Java およびプロセス管理 (Java and Process Management)」→「プ
ロセス定義 (Process Definition)」→「環境エントリー (Environment Entries)」→「新規 (New)」
→「EXTSHM=OFF」(注: EXTSHM がオンのとき、大容量ページは使用できません) にナビゲ
ートします。
4. 使用可能な大容量ページ数を動的に割り当てるには、以下のコマンドを発行します。
echo 3072 > /proc/sys/vm/nr_hugepages
(これは再始動中に設定する必要があります。)
5. 再始動中に再始動値を永続的に設定するには、/etc/sysctl.conf を編集して以下の行を追
加します。vm.nr_hugepages=3072
6. 大容量ページが使用されているかどうかを検証するには、以下のコマンドを発行します。
grep Huge /proc/meminfo
以下の情報が表示されます。
HugePages_Total: 3072
HugePages_Free: 3072
15
WEBSPHERE PORTAL 7.0 TUNING GUIDE
HugePages_Rsvd: 0
Hugepagesize:2048 KB
7. Portal サーバーを再始動します。
パラメー
AIX
Linux
Solaris
ター
JVM ヒ ー
Windows
z/Linux
z/OS
-Xlp
該当なし
2003
-Xlp
-Xlp
該当なし
該当なし
プの大容
量ページ
16
WEBSPHERE PORTAL 7.0 TUNING GUIDE
JVM ヒープの新しい領域のサイズ
IBM Java 5 JVM には新しいガーベッジ・コレクターである世代間同時ガーベッジ・コレク
ターが導入されています。測定の結果、このガーベッジ・コレクターによってパフォーマ
ンスが向上することが判明したため、新しい Web Sphere Portal 7.0 のインストールではデ
フォルトで有効化されます。これは、JVM コマンド・ライン引数の -Xgcpolicy:gencon に
よって有効化されます。このガーベッジ・コレクターは、Nursery (新しいオブジェクトが割
り当てられるスペース) のサイズを設定することで微調整できます。そのためには、-Xmn
コマンド・ライン・オプションを使用します。シナリオでは、JVM が新しい領域 (Nursery)
のサイズを下回っているときに、下記の推奨値までサイズを増やすと、スループットが向
上することが確認されました。
Solaris では、世代間のガーベッジ・コレクターはデフォルトであるあるためオプション
-Xgcpolicy:gencon は適用されません。
設定方法: WebSphere の管理コンソールから: 「サーバー (Servers)」→「アプリケーショ
ン・サーバー (Application Servers)」→「WebSphere Portal」→サーバー・インフラストラク
チャー(Server Infrastructure): 「Java およびプロセス管理 (Java and Process Management)」
→「プロセス定義 (Process Definition)」→「Java 仮想マシン (Java Virtual Machine)」→「汎
用 JVM 引数 (Generic JVM Arguments): －Xmnxxxm」にナビゲートします。
パラメーター
AIX
Linux
Solaris
Windows
z/Linux
z/OS
N/M
未サポー
2003
新しい領
32 ビ ッ
域のサイ
ト
ズ
64 ビ ッ
512
256
N/M
256
ト
1024
N/M
768
256
682
320
ト
注: Solaris では、Nursery のサイズはオプション －XX:NewSize を使用しても指定できます。
「N/M」の意味は「未測定」ではありません。
共有クラスのキャッシュ・サイズ
IBM JVM のクラス共有は、アプリケーション・クラスとシステム・クラスの両方の、読み
17
WEBSPHERE PORTAL 7.0 TUNING GUIDE
込まれたすべてのクラスを透過的かつ動的に共有する手段を提供します。この機能の詳細
については、
「IBM Java Diagnostics Guide」を参照してください。パフォーマンス面では、
キャッシュが作成されると、JVM の起動時間を短縮できます。また、複数の JVM がキャ
ッシュを共有している場合に必要となる仮想ストレージを減らすこともできます。
WebSphere Application Server は、クラス・データの共有をデフォルトで可能にし、このキ
ャッシュのサイズを 50MB に設定します。多くの WebSphere Portal アプリケーションは
50MB を超える共有クラス・データを持つことになるため、このキャッシュ・サイズを増や
すことでさらにメリットが得られます。ポータルの起動後に約 75MB が使用されることが
判明したため、120MB の共有クラス・キャッシュ・サイズを使用して追加のアプリケーシ
ョンのための空き領域を確保できるようにしました。また、共有クラス・キャッシュのサ
イズを増やすと、複数回の測定にわたるパフォーマンスの結果の再現性が、とりわけ AIX に
ついて向上することが判明しました。
18
WEBSPHERE PORTAL 7.0 TUNING GUIDE
共有クラスのキャッシュはデプロイされるまで持続するため、サイズを変更する場合は、
最初にキャッシュを破棄する必要があります。
設定方法:
1. WebSphere の管理コンソールから: 「サーバー (Servers)」→「アプリケーション・サー
バー (Application Servers)」→「WebSphere Portal」→サーバー・インフラストラクチャー
(Server Infrastructure): 「Java およびプロセス管理 (Java and Process Management)」→「プ
ロセス定義 (Process Definition)」→「Java 仮想マシン (Java Virtual Machine)」→「汎用 JVM
引数 (Generic JVM Arguments): －Xscmxnnnm」にナビゲートします。
パラメーター
AIX
Linux
Solaris
Windows
z/Linux
z/OS
未使用
N/M
未使用
未使用
120
2003
キャッシ
32 ビ ッ
ュ・サイ
ト
ズ
64 ビ ッ
120
未使用
未使用
150
ト
2. キャッシュを削除します。
a. Portal サーバー、および WAS server1 を停止します。次に <AppServer root>/java/bin の
下に移動します。
b. 以下のコマンドを実行します。
AIX の場合:
java -Xshareclasses:name=webspherev70_%g,groupAccess,destroy
Windows の場合:
java -Xshareclasses:name=webspherev70,groupAccess,destroy
以下のメッセージが表示されます。
JVMSHRC010I Shared cache "webspherev70_system" is destroyed.
Could not create the Java virtual machine.
3. Portal サーバーを始動します。
4. 使用中のキャッシュ・サイズを確認します。
•
. java -Xshareclasses:name=webspherev70_%g,groupAccess,printStats
19
WEBSPHERE PORTAL 7.0 TUNING GUIDE
追加の JVM 引数
過度なガーベッジ・コレクションを回避するために 64 ビットのすべてのプラットフォー
ムでは、-XX:MaxDirectMemorySize=256000000 を使用することを推奨します。この JVM 引
数は上記のとおり正確に指定する必要があります。
追加の SUN JVM 引数
Solaris プラットフォームでは、以下の Java HotSpot パラメーターを使用して最適なパフ
ォーマンスを達成しています。
表 1:追加の Sun JVM 設定
パラメーター
値
-server
追加情報
「クライアント」モードよりも高いスループッ
トを提供します。
-XX:MaxPermSize
768m
-XX:+UseConcMarkSweepGC
現行の世代に対して同時マーク・スイープ・コ
レクションを使用します。アプリケーション
は、コレクション中に短時間休止されます。
Portal ではこのコレクターが最適に動作した
ことが判明しました。
-XX:SurvivorRatio
6
-XX:+UseParNewGC
デフォルトでは、同時の低一時停止コレクター
はデフォルトのシングル・スレッドの若い世代
をコピーするコレクターを使用します。新しい
領域には、並列の若い世代のコレクターを使用
するようにこのパラメーターを設定してくだ
さい。
-XX:ParallelGCThreads
5
ガーベッジ・スレッドの数を減らします。チッ
プ・マルチスレッド化プロセッサー・ベースの
システムでは、ハードウェア・スレッドの 4 分
の 1 以下のスレッドを設定します。また、6 つ
の JVM のスレッドも配布します。使用するシ
ステムには 128 基の仮想プロセッサーがあ
り、すべての JVM にわたって合計 (128/4)=32
GC のスレッドを設定します。そのため JVM
20
WEBSPHERE PORTAL 7.0 TUNING GUIDE
あたりの GC スレッド数は 5 つまたは 6 つ
です。
-XX:+PrintGCDetails
ガーベッジ・コレクションの詳細をプリントし
ます。これによってパフォーマンスが向上する
ことはありませんが、ガーベッジ・コレクショ
ンのアクティビティーに関連付けられた追加
情報が提供されます。これはガーベッジ・コレ
クションの調整に便利です。
-XX:+PrintGCTimeStamps
ガーベッジ・コレクションのタイムスタンプを
プリントします。上記を参照してください。
追加の Z/OS JVM 引数
z/OS の WebSphere Application Server には 3 つ以上の JVM があります。
21
WEBSPHERE PORTAL 7.0 TUNING GUIDE
1. Controller Region は、WLM を使用して要求を Servant Region に再キューイングするため
に使用されます。
2. Servant Region は、アプリケーション (Portal) コードを実行します。
3. Adjunct Region は、オプションの JVM ですが、Portal 構成向けに自動的に構成されます。
これは JMS エンジンを含みます。
最適なパフォーマンスを達成するには、十分なヒープ・サイズをすべての JVM 領域に割り
当てる必要があります。Servant Region のヒープ・サイズについては、上記のトピックで説
明しています。
Controller Region の初期/最大ヒープ・サイズ
設定方法:WebSphere の管理コンソールから: 「サーバー (Servers)」→「アプリケーション・
サーバー (Application Servers)」→「WebSphere Portal」→ サーバー・インフラストラクチ
ャー(Server Infrastructure): 「Java およびプロセス管理 (Java and Process Management)」→
「プロセス定義 (Process Definition)」→「制御 (Control)」→「Java 仮想マシン (Java Virtual
Machine)」にナビゲートします。
- 初期ヒープ・サイズ =1024
- 最大ヒープ・サイズ =1024
Adjunct Region の初期/最大ヒープ・サイズ
設定方法:WebSphere の管理コンソールから: 「サーバー (Servers)」→「アプリケーション・
サーバー (Application Servers)」→「WebSphere Portal」→ サーバー・インフラストラクチ
ャー(Server Infrastructure): 「Java およびプロセス管理 (Java and Process Management)」→
「プロセス定義 (Process Definition)」→「付属 (Adjunct)」→「Java 仮想マシン (Java Virtual
Machine)」にナビゲートします。
- 初期ヒープ・サイズ =1024
- 最大ヒープ・サイズ =1024
Z/OS での JVM ヒープ圧縮リファレンス・オプション
圧縮リファレンス・オプションは、2GB 以上のヒープ・サイズでの実行におけるパフォー
マ ン ス 上 の メ リ ッ ト を も た ら し ま す 。 こ の オ プ シ ョ ン は JVM 環 境 エ ン ト リ ー で
22
WEBSPHERE PORTAL 7.0 TUNING GUIDE
－Xcompressedrefs オプションを設定することで有効化されます。－Xcompressedrefs オプ
ションを 30GB 未満の －Xmx 値と共に指定すると、JVM は 2^31 から 2^35 までの仮想
範囲内で Java ヒープを割り当てようとします。
64 ビットの JVM を有効にして圧縮リファレンス・モードで実行するには、WebSphere
Application Server 構成で新しい環境変数を指定する必要があります。
•
管理コンソールから、「サーバー (Servers)」→「サーバー・タイプ (Server Types)」→
「 WebSphere ア プ リ ケ ー シ ョ ン ・ サ ー バ ー (WebSphere application servers) 」 →
「server_name」の順にクリックします。
•
「構成 (Configuration)」タブをクリックして、「サーバー･インフラストラクチャー
(Server Infrastructure)」セクションの下の「Java およびプロセス管理 (Java and process
management)」→「プロセス定義 (Process Definition)」→「サーバント (servant)」をク
リックします。
•
次に、追加のプロパティー・セクションで「環境 (Environment)」エントリーをクリッ
クします。
IBM_JAVA_OPTIONS の環境エントリーを次のように追加/更新します。
23
WEBSPHERE PORTAL 7.0 TUNING GUIDE
•
IBM_JAVA_OPTIONS という既存の環境エントリーが確認されたら、これを編集して
Java オプションの –Xcompressedrefs を既存の値に付加します。
•
確認されない場合は、「新規 (New)」をクリックして新しい環境エントリーを作成しま
す。
•
フォームの各フィールドに以下の値を入力します。
「名前 (Name)」:IBM_JAVA_OPTIONS
「値 (Value)」:-Xcompressedrefs
「説明 (Description)」:64 ビットの圧縮リファレンス・モードを有効にします
•
「適用」をクリックして WebSphere Application Server 環境を更新します。
•
WebSphere Application Server を再始動して、WebSphere Application Server を圧縮リフ
ァレンス・モードで始動します。
JDK の修正
Java 6 SR7 を使用して Portal を実行する 64 ビットのプラットフォームについては、以下
の修正を適用して JIT コードのキャッシュがいっぱいになる問題を回避することをお勧め
します。
•
APAR IZ73637:デフォルトの JIT コードのキャッシュ・サイズを 128MB に増やします。
•
APAR IZ69136:JIT コードのキャッシュがいっぱいになると Java Interpreter Profiler
(JIP) を無効にします。
上記の APAR は Java 6 SR8 に取り込まれています。
セッション・タイムアウト
セッション・タイムアウト:
セッション・タイムアウトのデフォルト値は 30 分です。こ
の値をより低い数に減らすと、メモリー消費要件の軽減に役立ち、より長い時間にわたっ
て、より多くのユーザー数を保持できるようになります。この値を減らしすぎると、ユー
ザー・エクスペリエンスの妨げとなることがあります。
Solaris については、 T5240 プラットフォーム上では、他のプラットフォーム・ハードウェ
ア測定に使用した 12 秒よりもはるかに短い 5 秒という待ち時間を使用しました。待ち時
間が短いほど仮想ユーザー数が減り、システムへの負担が増大することになります。待ち
24
WEBSPHERE PORTAL 7.0 TUNING GUIDE
時間を短くした具体的な理由は、この測定に必要な仮想ユーザー数を減らすことにありま
した。LoadRunner 仮想ユーザー・ライセンスのプールは、より長い待ち時間では十分なロ
ードを生成できませんでした。他の測定で用いられた短い待機時間では、各仮想ユーザー
とサイトとの対話期間が約 2 分短縮されました。これを補い、サーバーでのセッション・
ライブを同じ期間保持するために、セッション・タイムアウトを 2 分増やし、12 分にし
ました。
設定方法:
WebSphere の管理コンソールから: 「サーバー (Servers)」→「アプリケーショ
ン・サーバー (Application Servers)」→「WebSphere Portal」→「コンテナー設定: Web コン
テナーの設定 (Container Settings: Web Container Settings)」→「セッション管理 (Session
Management)」→「セッション・タイムアウト (Session Timeout)」→「タイムアウトの設定
(Set Timeout)」にナビゲートします。
25
WEBSPHERE PORTAL 7.0 TUNING GUIDE
パラメー
AIX
Linux
Solaris
ター
セッショ
Windows
z/Linux
z/OS
10 分
10 分
2003
10 分
10 分
12 分
10 分
ン・タイム
アウト
Web コンテナー・スレッド・プールのサイズ
Servlet エンジン・スレッド・プールのサイズ:この値を設定して結果をモニターします。す
べての servlet スレッドがほとんど常に使用中である場合は、この値を増やしてください。
設定方法: WebSphere の管理コンソールから、
「サーバー (Servers)」→「アプリケーション・
サーバー (Application Servers)」→「WebSphere Portal」→「追加のプロパティー: スレッド・
プール (Additional Properties: Thread Pools)」→「Web コンテナー (Web Container)」→「ス
レッド・プール - 最小サイズ・スレッド - 最大サイズ・スレッド (Thread Pool - Minimum
size threads - Maximum size threads)」にナビゲートします。
パラメー
AIX
Linux
Solaris
ター
Web コ ン
Windows
z/Linux
z/OS
50
50
2003
50
50
50
50
テナー・ス
レッド・プ
ールのサ
イズ
データ・ソースのチューニング
WebSphere Portal V7.0 では複数のデータベースを使用して情報を保持しています。DB2 で
は 6 つの別個のデータベースを使用しました。これらはそれぞれが別個のデータベース・
ドメインを表し、それぞれ独自のデータ・ソースを持ちます。これらのデータベースは以
下のとおりです。
26
WEBSPHERE PORTAL 7.0 TUNING GUIDE
表 2:データベース・ドメイン
データベース
データベース名
データ・ソース名
Release
release
reldbDS
Community
community
commdbDS
Customization
custom
cusdbDS
Feedback
fdbkdb
fdbkdbDS
Likeminds
lmdb
lmdbDS
JCR
jcrdb
jcrdbDS
Oracle の場合では、単一のデータベースを構築して、各ドメインのサポートに必要な表と
データを所有する Oracle ユーザーを作成しました。ドメインは上記と同じです。
すべてのデータ・ソースが同じような方法で構成されます。設定済みステートメント・キ
ャッシュ・サイズには、デフォルトの設定が使用されます。
27
WEBSPHERE PORTAL 7.0 TUNING GUIDE
設定方法:
WebSphere の管理コンソールから、
「リソース (Resources)」→「JDBC プロバ
イダー (JDBC Providers)」→「プロバイダー名」→「データ・ソース (Data Sources)」→「デ
ー タ ・ ソ ー ス 名 」 → 「 WebSphere Application Server デ ー タ ・ ソ ー ス の プ ロ パ テ ィ ー
(WebSphere Application Server data source properties)」→「ステートメント・キャッシュ・
サイズ (Statement cache size)」にナビゲートします。
プロバイダー名とデータ・ソース名は、データベースの転送手順中にそのデータベースに
対して選択した名前に基づきます。
パラメー
AIX
Linux
Solaris
ター
ステート
Windows
z/Linux
z/OS
10
10
2003
10
10
10
10
メント・キ
ャ ッ シ
ュ・サイズ
基本ポータル・シナリオでは、接続プールの最小サイズと最大サイズにデフォルトの設定
が使用されました。WCM については、より高い最小/最大接続プール・サイズが必要です。
並列ポートレットのレンダリングを使用したり、より大きな WebContainer スレッド・プー
ルを使用したりする場合には、これよりも大きな接続プールのサイズが必要となる場合も
あります。いかなる場合でも、データベース接続プールをモニターして、プールの利用率
が最大限に達している場合は最大サイズを増やすことをお勧めします。
設定方法:
WebSphere の管理コンソールから、「リソース (Resources)」→「JDBC プロバ
イダー (JDBC Providers)」→「プロバイダー名」→「データ・ソース (Data Sources)」→「デ
ータ・ソース名」→「接続プールのプロパティー (Connection pool properties)」→「最大/
最小接続 (Maximum/Minimum connections)」にナビゲートします。
パラメー
AIX
Linux
Solaris
ター
最大 /最小
Windows
z/Linux
z/OS
50/10
50/10
2003
50/10
50/10
50/10
50/10
接続
ワークロードによるアプリケーション・メモリーの使用率が高い状況では、より大きなス
テートメント・キャッシュ・サイズを指定すると、OutOfMemory エラーを引き起こすこと
28
WEBSPHERE PORTAL 7.0 TUNING GUIDE
があるので注意してください。また、ワークロードによっては、設定済みキャッシュ・ス
テートメント・サイズを増やしてもメリットがないものもあります。例えば、WCM ワーク
ロードでは、JCR データベースに対して生成された SQL ステートメントの動的な性質に
より、すべてのさまざまな置換をカバーするためにキャッシュ・サイズが非常に大きくな
る必要があり、ヒット率はきわめて低くなります。そのような場合、キャッシュのサイズ
を増やしてメモリー・リソースを空けるべきです。
結局のところ、設定済みステート・キャッシュ・サイズは、データベース接続ごとの最大
許容キャッシュ・エントリーであるため、接続数が多いデータ・ソースに対してこのキャ
ッシュ・サイズを増やせば、これらのキャッシュ・オブジェクトに対するヒープ使用率を
すぐに上げることができます。どのような変更も、すべてのデータ・ソース全体に対して
の適用を検討するのではなく、各データ・ソースに対しての適用を検討する必要がありま
す。データ・ソースの設定済みステートメント・キャッシュ・サイズを増やす前に、ワー
クロードが大きいときのメモリー使用量をモニターして、増やすサイズを処理できるだけ
のメモリー・リソースが使用可能であるかどうかを判断する必要があります。
セキュリティー属性伝搬
セキュリティー属性伝搬 (SAP) のオーバーヘッドを減らすには、カスタム・プロパティー
「disable Callerlist」を使用してください。SAP が使用されていない場合は、これを無効に
して追加のオーバーヘッドをなくすことでログインのパフォーマンスを改善できます。
WebSphere Subject が Trust Association Intercepter (TAI) やカスタム WAS ログイン・モジ
ュールなどを介してカスタマイズされていない場合は、セキュリティー属性伝搬を有効にする
必要はありません。セキュリティー属性伝搬では、追加処理が必要であるため、追加のオーバーヘッド
が生じることがあります。ただし、リモート・レジストリー・コールを低減することで、セキュリティー属性伝搬を
利用しながらパフォーマンスを向上させるという構成があります。セキュリティー属性の伝搬がどのよ
うな場合に望ましいかについては、WebSphere 7.0 InfoCenter (「セキュリティー属性伝搬」
で検索) を参照してください。機能上の理由により SAP を有効化したい場合は、後述する
CallerList のチューニングによってパフォーマンスを改善できます。
これらの設定はすべてのプラットフォームに適用されます。
設定方法: WebSphere の管理コンソールから、「セキュリティー (Security)」→「セキュア
な管理、アプリケーション、インフラストラクチャー (Secure Administration, Applications, and
Infrastructure)」→「カスタム・プロパティー (Custom properties)」にナビゲートします。
29
WEBSPHERE PORTAL 7.0 TUNING GUIDE
表 3: WebSphere セキュリティー属性伝搬の設定
セキュリティー属性伝搬
名前
値
com.ibm.CSI.disablePropagatio
true
nCallerList
「com.ibm.CSI.disablePropagationCallerList」という新しいカスタム・プロパティーを作成し、
その値に「true」を設定します。
Internationalization Service のチューニング
国際化されたアプリケーションは、文化的に適切な方法でさまざまな地域のユーザーと対
話するように構成できます。Internationalization Service を使用すると、全社的にコンポーネ
ントが配布されるアプリケーションの国際化対応コンテキストを構成および管理できます。
ただし、この機能は不要であれば無効にすることでオーバーヘッドを減らすことができま
す。
設定方法: WebSphere の管理コンソールから、
「サーバー (Servers)」→「アプリケーション・
サ ー バ ー (Application Servers) 」 → 「 WebSphere Portal 」 → 「 コ ン テ ナ ー ・ サ ー ビ ス :
Internationalization Service (Container Services: Internationalization Service)」にナビゲートし、
「サーバー起動時にサービスを有効化 (Enable service at server start up)」のチェック・マー
クを外します。
これらの設定はすべてのプラットフォームに適用されます。
30
WEBSPHERE PORTAL 7.0 TUNING GUIDE
タグ付けと格付けの無効化
タグ付けと格付けのサービスを使用しない場合は、これらを無効化できます。測定ではこ
れらを無効にすることで、キャパシティーが 3% 改善されました。無効化するには、次に
示すパラメーターを設定します。
設定方法: WebSphere 管理コンソールで、
「サーバー (Servers)」→「リソース (Resources)」
→「リソース環境 (Resource Environment)」→「リソース環境プロバイダー (Resource
Environment Providers)」→「WP_CPConfigurationService」にナビゲートします。
表 4:タグ付けと格付けの設定
com.ibm.wps.cp.tagging.isTaggi
デフォルト値
値
True
False
True
False
ngEnabled
com.ibm.wps.cp.rating.isRating
Enabled
フレンドリー URL の無効化
フレンドリー URL では、ブラウザーのアドレス・フィールドに意味のある名前を配置する
ことで、エンド・ユーザー・エクスペリエンスを向上させます。ただし、フレンドリー URL
を使用すると負荷がかかります。フレンドリー URL を無効化すると、テーマによってはキ
ャパシティーが 2% 以上改善されることが測定されています。
ブ ロ グ や Wiki 、 WCM コ ン テ ン ツ ・ ペ ー ジ を 使 用 す る 場 合 、 friendly.enabled ま た は
friendly.pathinfo.enabled
を
false
に 設 定 し な い で く だ さ い 。 詳 細 は 、
http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Working_with_friendly_URLs_for_web_content_lwc
m7 を参照してください。
フレンドリー URL をフルに使用するには、ページをフレンドリー名で構成する必要があり
ます。
フレンドリー URL は、次のパラメーターを設定することで無効化できます。
設 定 方 法 : WebSphere の 管 理 コ ン ソ ー ル か ら 、「 サ ー バ ー (Servers) 」 → 「 リ ソ ー ス
31
WEBSPHERE PORTAL 7.0 TUNING GUIDE
(Resources)」→「リソース環境 (Resource Environment)」→「リソース環境プロバイダー (Resource
Environment Providers)」→「WP_ConfigService」にナビゲートします。
次のカスタム・プロパティーを追加します。
表 5: フレンドリー URL の設定
デフォルト値
値
friendly.enabled
True
False
friendly.pathinfo.enabled
True
False
friendly.enabled を false に設定すると、Portal はフレンドリー URL を使用しなくなります。
friendly.pathinfo.enabled を false に設定すると、WCM はフレンドリー URL を使用しなくな
ります。インストール時に WCM を使用せず、フレンドリー名がポータルで使用されてい
る場合でも、friendly.pathinfo.enabled を false に設定すると有利です。
32
WEBSPHERE PORTAL 7.0 TUNING GUIDE
LTPA のチューニング
LTPA トークンは WebSphere の認証プロセス部分で使用されます。LTPA トークンの暗号
化された署名の計算は負荷の高い処理ですが、PM16589 をインストールして次のようにカ
スタム・セキュリティー・プロパティーを設定することで改善できます。この変更による
機能への影響はありません。
設定方法: WebSphere の管理コンソールから、
「セキュリティー (Security)」→「グローバ
ル・セキュリティー (Global Security)」→「カスタム・プロパティー (Custom properties)」
にナビゲートします。
表 6: WebSphere Security LPTA2 の設定
Security LTPA
名前
値
com.ibm.ws.security.ltpa.useC
True
RT
「com.ibm.ws.security.ltpa.useCRT」という新しいカスタム・プロパティーを作成し、その値
に「true」を設定します。
テーマのベース URL の有効化
ベース URL を有効にすることで、リダイレクトと URL 生成のための処理を減らすことが
できます。これは、Portal 6.1.5 と Portal 7.0 に付属しているデフォルト・テーマ、および
それらの派生テーマに有効です。
ベース URL を有効にすると、多くの構成において、WP_ConfigService に host.name を設定
する必要があります。host.name には、エンド･ユーザーがポータルとわかる値を設定する
必要があります。例えば、リバース・プロキシーや仮想ポータルを使用している場合、
WP_ConfigService の host.name はそのリバース・プロキシーや仮想ポータルの名前にする
必要があります。
設定方法: コマンド・プロンプトで XMLAccess ツールを使用して次に示すように xml 入
力ファイルをインポートします。
Windows の場合:
xmlaccess.bat -in redirectOff.xml -user wpsadmin -password wpsadmin -url
http://<hostname>:10039/wps/config
33
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Unix の場合:
./xmlaccess.sh -in redirectOff.xml -user wpsadmin -password wpsadmin -url
http://<hostname>:10039/wps/config
Portal 6.15 の デ フ ォ ル ト Page Builder に よ っ て basehref を 有 効 化 す る た め の
redirectOff.xml の内容:
<?xml version="1.0" encoding="UTF-8"?>
<request build="wpnext_372_01" type="update" version="7.0.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd">
34
WEBSPHERE PORTAL 7.0 TUNING GUIDE
<portal action="locate">
<theme action="update" uniquename="ibm.portal.theme.enhanced">
<parameter name="com.ibm.portal.theme.hasBaseURL"
type="string" update="set">true</parameter>
</theme>
</portal>
</request>
Portal 7.0 のデフォルト Page Builder によって basehref を有効化するための
redirectOff.xml の内容:
<?xml version="1.0" encoding="UTF-8"?>
<request build="wpnext_372_01" type="update" version="7.0.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd">
<portal action="locate">
<theme action="update" uniquename="csa2.theme">
<parameter name="com.ibm.portal.theme.hasBaseURL"
type="string" update="set">true</parameter>
</theme>
</portal>
</request>
検索の無効化
検索機能が不要であれば、これを無効にすることでパフォーマンスを改善できます。
設定方法:
WebSphere Portal の 管 理 ペ ー ジ か ら 「 検 索 管 理 / 管 理 検 索 (Search
Administration/Manage Search)」→「検索コレクション (Search Collections)」→「WebSphere
Portal」→「ポートレット・コンテナー」→「すべてのコレクションを削除 (Delete all
collections)」にナビゲートします。
35
WEBSPHERE PORTAL 7.0 TUNING GUIDE
VMM のチューニング
VMM コンテキスト・プール
VMM コンテキスト・プールをチューニングすることで、LDAP サーバーへの同時アクセス
のパフォーマンスが向上します。
次 の よ う に
Context
Pooling
設 定 の 行 を 変 更 し ま し た 。
<wp_profile_root>/config/cells/<cellname>/wim/config/wimconfig.xml
<config:contextPool enabled="true" initPoolSize="10" maxPoolSize="30" poolTimeOut="0"
poolWaitTime="3000" prefPoolSize="30"/>
36
WEBSPHERE PORTAL 7.0 TUNING GUIDE
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.bas
e.doc/info/aes/ae/uwim_ldapperfsettings.html に記載されているとおり、管理コンソールから
も設定可能です。
表 7: VMM コンテキスト・プールの設定
コンテキスト・プー
デフォルト値
値
initPoolSize
1
10
prefPoolSize
3
30
その他の詳細
ルの設定
維持する LDAP サーバーへのオープン接
続数 AIX Power6 64 ビットの測定では 40
を使用しています。
maxPoolSize
20
30
0 を設定すると、必要に応じてプール領域
を拡大できます。LDAP サーバーへのアク
セスを複数のシステムで共有している場合
は、この設定によって LDAP サーバーへの
接続数が多くなりすぎることがあります。
そのような場合は、お使いの環境に適した
最大プール・サイズを設定してください。
AIX Power6 64 ビットの測定では 40 を使
用しています。
VMM 検索結果のキャッシュ
VMM 検索のパフォーマンスを改善するには、Tune VMM 検索結果のキャッシュをチューニ
ングします。
次のように searchResultsCache 設定の行を変更しました。
<wp_profile_root>/config/cells/<cellname>/wim/config/wimconfig.xml
<config:searchResultsCache
cacheSize="4000"
cacheTimeOut="600"
enabled="true"
searchResultSizeLimit="1000"/>
表 8: VMM キャッシュの設定
VMM キ ャ ッ シ ュ の
デフォルト値
値
その他の詳細
2000
4000
AIX Power6 64 ビットの測定では 5000
設定
cacheSize
を使用しています。
37
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Z/OS の ORB サービスのチューニング
我々のベンチマーク・シナリオでは、ポータル・アプリケーションがリモート・データベ
ースやトランザクション管理システムに接続しないため、最小限のスレッド数で最良のス
ループットを得ることができました。お使いの環境でアプリケーションがリモート・シス
テムに接続する場合は、それに応じて ORB スレッド数を設定する必要があります。負荷の
増大に応じて CPU 使用率を上げることができるだけのスレッド数を確保する必要があり
ます。
測定では ORB Container Services で CUSTOM ワークロード・プロファイルを使用し、
WebSphere 変数で定義された servant_region_custom_thread_count property を使用して ORB
スレッド数を定義しました。
ワークロード・プロファイル・タイプの設定
•
WebSphere の管理コンソールから、
「サーバー (Servers)」→「サーバー・タイプ (Server
Types)」→「WebSphere アプリケーション・サーバー (WebSphere application servers)」
→「server_name」の順にクリックします。
•
「コンテナー設定 (Container Settings)」で「コンテナー・サービス (Container Services)」
→「ORB サービス (ORB Service)」をクリックします
•
「追加のプロパティー (Additional Properties)」で「z/OS 追加設定 (z/OS additional
setting)」をクリックします。
•
「ワークロード・プロファイル (Workload Profile)」でワークロード・プロファイル・タ
イプとして CUSTOM を選択します。 「適用 (Apply)」をクリックします。
ORB スレッド数の設定
•
管理コンソールの「環境 (Environment)」から、
「WebSphere 変数 (WebSphere Varaibles)」
をクリックします。
•
範囲に「Portal Server」を選択します。
•
既存の Variable servant_region_custom_thread_count を更新するか、新たに定義して、お
使いの環境に適した数に値を設定します。サーバントあたり最大 100 個のスレッドを
設定できます。
•
「適用」をクリックし、サーバーを再始動します。
38
WEBSPHERE PORTAL 7.0 TUNING GUIDE
WebSphere Portal Service
WebSphere Portal には複数の設定可能な「サービス」があり、各サービスにはそれぞれに
利用可能な複数のパラメーターがあります。ここでは、チューニングしたサービスと、使
用したチューニング値、そしてこれらの変更の理論的根拠について説明します。
設定方法:
1. <wp_profile_root>/PortalServer/config/properties/xxxService.properties を編集します。
2. 行をアンコメントして、サイズを変更します。
3. <wp_profile_root>/ConfigEngine/ConfigEngine.sh update-properties を実行します。
WebSphere 統合ソリューション・コンソールの「リソース (Resources)」→「リソース環境
(Resource Environment)」→「リソース環境プロバイダー (Resource Environment Providers)」
→「WP_xxxService」→「カスタム・プロパティー (Custom properties)」パスの下で変更が
確認できます。
39
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ナビゲーター・サービス
ナビゲーター・サービスは認証されていないユーザーのコンテンツ・モデルを管理し、こ
れらのユーザーが参照可能なページを制御します。このコンテンツ・モデルは WebSphere
ポータルによって定期的に再ロードされますが、認証されていないユーザーが参照可能な
新しいページは、次に再ロードされるまで利用できません。我々の環境ではページ変更の
率が低いことが想定されたため、この再ロードは 1 時間あたり 1 回に設定しました。認
証されていないユーザーに対するページが作成されることがまれな実稼働環境では、この
再ロード時間を 1 時間以上にすれば、より優れたパフォーマンスが得られます。承認され
ていないページの更新が頻繁に必要なテストやステージング環境では、再ロードの間隔を
より短くすることが適しています。
このサービスでは、承認されていないページで送信される HTTP のキャッシュ制御ヘッダ
ーも制御します。我々の環境では HTTP ページ・キャッシュを活用していなかったため、
実稼働環境でこれらのキャッシュの存続時間を増やすことで、ポータルへの負荷を軽減で
きます。WebSphere ポータルでの HTTP キャッシュ制御ヘッダーの利用に関する詳細は、
WebSphere Portal V7.0 InfoCenter の「Tuning」トピックの「Caching」セクションを参照して
ください。
40
WEBSPHERE PORTAL 7.0 TUNING GUIDE
表 9: ナビゲーション・サービスの設定
NavigatorService.properties
パラメーター
デフォルト値
使用する
定義
値
public.expires
60
3600
(秒)
ブラウザーのキャッシュとプロキシーのキャ
ッシュでの承認されていないページに対する
キャッシュの有効期限を定義します。
remote.cache.expiration にも 0 以上の値が設
定されると、2 つのうちどちらか小さい方の
値が使用されます。
public.reload
60
3600
(秒)
WebSphere Portal は承認されていないユーザ
ーが参照可能なページ一覧の内部キャッシ
ュ、およびこれらのページのポートレットの
配置を維持します。これは内部キャッシュを
更新する頻度を制御します。ただし、これら
のページは内容がキャッシュされるのではな
く単にレイアウトがキャッシュされることに
注意してください。
remote.cache.
10800
expiration (秒)
28800
承認されていないページ、および承認された
ページのポータル・サーバーの外部にあるキ
ャッシュの有効期限を決定します。
レジストリー・サービス
WebSphere ポータルは、多くのリソース・タイプに関する情報をそのデータベース内に維
持します。これらのリソースのいくつかは、アクセス速度を速めるためにレジストリー・
サービスによってメモリーに複製されます。この複製された情報はデータベースから定期
的に再ロードされ、クラスター化された環境のピア・ノードに行われている変更がピック
アップされます。
レジストリー・サービスでは、管理対象のデータごとに再ロードする時間 (秒単位) を構成
できます。実稼働環境では、この種の情報の変更がまれであると予測されるため、レジス
トリー・サービスの再ロード時間をかなり長くしました。これらの値はデータベースの完
全な複製であるため、サイズのパラメーターは含みません。レジストリー・サービスが管
理する情報の種類の完全な一覧を表 7 に示します。
41
WEBSPHERE PORTAL 7.0 TUNING GUIDE
表 10: レジストリー・サービスの設定
RegistryService.properties
パラメーター
デフォルト値
使用する
定義
値
default.interval
1800
28800
ファイルに明確に定義されていないオブジ
ェクト種別の再ロード頻度。
bucket.theme.i
3000
28800
テーマ定義の再ロード頻度
3500
28800
スキン定義の再ロード頻度
19000
28800
クライアント定義の再ロード頻度
20000
28800
マークアップ定義の再ロード頻度
600
28800
変換アプリケーション定義の再ロード頻度
600
28800
変換定義の再ロード頻度
nterval
bucket.skin.inte
rval
bucket.client.in
terval
bucket.markup.i
nterval
bucket.transfor
mation
application.inte
rval
bucket.transfor
mation. interval
キャッシュ・マネージャー・サービス
WebSphere Portal のキャッシュ・マネージャー・サービスは、各種さまざまな情報をメモ
リーにキャッシュするのに使用されます。これらのキャッシュは、各種の情報が自身のキ
ャッシュを持つという点から、レジストリー・サービスで維持されるレジストリーと多少
似ています。主な相違点は次のとおりです。
•
キャッシュ・マネージャー･サービスのキャッシュに保存される情報は、レジストリ
ー・サービスのレジストリーに保存される情報よりも動的になる傾向があります。
•
キャッシュ・マネージャー・サービスで使用されるキャッシュはサイズに制限があり、
キャッシュがいっぱいになるとエントリーが破棄されます。レジストリー・サービス
で使用されるレジストリーにサイズの制限はありません。これらは特定のデータ種別
のすべてのエントリーを含みます。
•
有効期限は、キャッシュ・マネージャー・サービスが管理するキャッシュ内のエント
リーごとに個々に管理されます。対照的に、レジストリーでは、再ロード時間に達す
ると、そのレジストリーの全内容が再ロードされます。
42
WEBSPHERE PORTAL 7.0 TUNING GUIDE
キャッシュにはそれぞれ複数の構成可能なオプションがあります。これらのオプションの
詳細は WebSphere Portal V7.0 のキャッシュ一覧と共に、第 2 章で説明します。また、表 8 にキャ
ッシュ・マネージャー・サービスの構成ファイルに行った変更を一覧します。サイズ値は「オ
ブジェクト数」で指定され、持続時間値は「秒」で指定されます。
43
WEBSPHERE PORTAL 7.0 TUNING GUIDE
表 11: キャッシュ・マネージャー・サービスの設定
CacheManagerService.properties
キャッシュ名
デフォルト値
使用する値
cacheinstance.com.lotus.cs.se
2000
2600
TRUE
FALSE
TRUE
FALSE
TRUE
FALSE
3600
-1
TRUE
FALSE
TRUE
FALSE
TRUE
FALSE
1500
3000
500
1500
rvices.UserEnvironment.size
cacheinstance.com.ibm.wps.sp
a.parser.theme.
ThemeParserCache.enableDis
kOffload
cacheinstance.com.ibm.wps.sp
a.parser.skin.
SkinParserCache.enableDiskO
ffload
cacheinstance.com.ibm.wps.sp
a.parser.locale.
LocalizationParserCache.enabl
eDiskOffload
cacheinstance.com.ibm.wps.se
rvices.vpmapping.
HostnameToVirtualPortalIDCa
che.lifetime
cacheinstance.com.ibm.wps.re
solver.service.
PortalPocBootstrapService.en
ableDiskOffload
cacheinstance.com.ibm.wps.re
solver.service.
PocServiceOnRequestImpl.cac
he.enableDiskOffload
cacheinstance.com.ibm.wps.re
solver.data.cache.
DataSourceCache.enableDisk
Offload
cacheinstance.com.ibm.wps.pu
ma.OID_User_Cache.size
cacheinstance.com.ibm.wps.pu
44
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ma.OID_Group_Cache.size
cacheinstance.com.ibm.wps.pu
1500
3000
1500
3000
1500
10000
500
6000
7780
43200
10000
20000
5800
28800
ma.OID_DN_Cache.size
cacheinstance.com.ibm.wps.pu
ma.DN_User_Cache.size
cacheinstance.com.ibm.wps.pu
ma.DN_OID_Cache.size
cacheinstance.com.ibm.wps.pu
ma.DN_Group_Cache.size
cacheinstance.com.ibm.wps.po
licy.services.
PolicyCacheManager.lifetime
cacheinstance.com.ibm.wps.pe.
portletentity.size
cacheinstance.com.ibm.wps.pe.
portletentity.lifetime
3000
cacheinstance.com.ibm.wps.m
odel.factory.
ContentModelCache.live.size
cacheinstance.com.ibm.wps.da
2500
5000
10000
20000
FALSE
TRUE
10143
14400
10240
-1
TRUE
false
tastore.services.
Identification.SerializedOidStri
ng.cache.size
cacheinstance.com.ibm.wps.ac.
RolesCache.size
cacheinstance.com.ibm.wps.ac.
RolesCache.enabled
cacheinstance.com.ibm.wps.ac.
ProtectedResourceCache.
lifetime
cacheinstance.com.ibm.wps.ac.
PermissionCollectionCache.
lifetime
cacheinstance.com.ibm.wps.ac.
OwnedResourcesCache.enabl
ed
45
WEBSPHERE PORTAL 7.0 TUNING GUIDE
cacheinstance.com.ibm.wps.ac.
8640
-1
1000
2000
7200
28800
ExternalOIDCache.lifetime
cacheinstance.com.ibm.wps.ac.
ExplicitEntitlementsCache.
USER_GROUP.size
cacheinstance.com.ibm.wps.ac.
ChildResourcesCache.
lifetime
適度
cacheinstance.com.ibm.workpl
ace.searchmenu.helper.
SearchMenuCacheHelper.repla
cement
cacheinstance.DigestCache.ca
25000
che.size
AIX Power6 環境では、上記の設定を以下のように変更しました。より最新のプロセッサー
(Power6 や Power7 などのプロセッサー) を使用した環境下では、これらの設定がパフォーマンスを
改善すると予測されます。
キャッシュ名
デフォルト値
使用する値
cacheinstance.com.lotus.cs.services.UserEnvironment.size
2000
4000
cacheinstance.com.ibm.wps.puma.OID_User_Cache.size
1500
5000
cacheinstance.com.ibm.wps.puma.OID_Group_Cache.size
500
2000
cacheinstance.com.ibm.wps.puma.OID_DN_Cache.size
1500
5000
cacheinstance.com.ibm.wps.puma.DN_User_Cache.size
1500
5000
cacheinstance.com.ibm.wps.puma.DN_Group_Cache.size
500
10000
cacheinstance.com.ibm.wps.pe.portletentity.size
10000
40000
cacheinstance.com.ibm.wps.model.factory.
10000
ContentModelCache.live.size
cacheinstance.DigestCache.cache.size
40000
データベースのチューニング
DB2 データベース・サーバーのチューニング
WebSphere Portal V7.0 は、データベース・サーバーをコア機能として使用します。測定環
46
WEBSPHERE PORTAL 7.0 TUNING GUIDE
境では、Portal アプリケーションに DB2 データベース・サーバーを使用しました。LDAP サ
ーバーとして使用した IBM Tivoli Directory Server でも同様に、リポジトリーとして DB2
データベースを取り入れましたが、このデータベースはほとんど使用されないため、追加
の構成は行わずに運用しました。
最大限のキャパシティーを得るために、リモート・データベース・サーバーの使用をお勧
めします。測定では、データベース・サーバーに IBM DB2 Enterprise Edition V9.7 フィック
スパック 1 を使用しました。WebSphere Portal V7.0 は、データベース・ドメインの概念を
使用しており、1 つのドメインに属している複数の表のグループを指定するか、あるいは、
まったく別個のデータベースを指定して、各ドメインに固有のデータを保管します。
各ドメインのサポートに必要な表およびデータを格納するために、1 つのデータベース・
サーバー内に 6 つの異なるデータベースを構築しました。基本ポータルの測定および大量
ページの測定では、リリース・ドメインを 1 次データベースとして使用します。
Portal V7.0 でサポートされるデータベースおよび関連ドメインは以下のとおりです。
1. リリース (リリース・ドメイン)。これは、基本ポータル・シナリオおよび大量ページ・
シナリオで使用する 1 次データベース・ドメインです。
2. カスタマイズ (カスタマイズ・ドメイン)。本書のシナリオでは、このデータベースに対
するトラフィック量はわずかです。
3. コミュニティー (コミュニティー・ドメイン)。本書のシナリオでは、このデータベース
に対するトラフィック量はわずかです。
4. JCR (JCR ドメイン)。JCR データベースは、WCM (Web Content Management) シナリオで
頻繁に使用します。ベンチマーク・レポートで測定したそのほかのシナリオではすべて、
このデータベースに対するトラフィック量はわずかです。
5. Likeminds データベース。Likeminds 対応のシステムで使用します。このデータベースは、
ベンチマーク・レポートで測定したシナリオでは使用しません。
6. フィードバック・データベース。フィードバック・サブシステムで使用します。このデ
ータベースは、このレポートで測定したシナリオでは使用しません。
AIX における DB2 のセットアップ
以下のセットアップを使用して、AIX に DB2 データベースを構成します。
47
WEBSPHERE PORTAL 7.0 TUNING GUIDE
•
Portal のデータベースを格納するファイル・システムを Enhanced Journal File System
(JFS2) に設定します。これは、大容量ファイル・システムのサイズが最大で 64GB に
制限されるためです。
•
Enhanced Journal File System で Concurrent I/O (CIO) を使用可能にすることにより、
パフォーマンスが向上します。
CIO を有効化するには、次のコマンドを使用してデータベース・ファイル・システムをマ
ウントします。
mount .o cio /portaldb
•
AIX の ユーザーあたりの最大プロセス数を 4096 に増やします。
デフォルトのユーザーあたりのプロセス数は 500 ですが、データベース・サーバーの場合、
この値では低すぎるため、本書の AIX 環境では 4096 に増やします。この値を増やすには、
次のように実行します。
chdev .l sys0 .a maxuproc=.4096.
Portal のデータベースは、高キャパシティー・パフォーマンス向けに構成されていますが、
その時々に応じて、さまざまなチューニングが必要になる場合があります。通常、これら
のチューニングは、データベースのトラフィック量と転送する表のサイズに基づいて行い
ます。
データベースのチューニングの設定については、Portal のインフォメーション・センター
で『リモート・データベースの作成』セクションを参照してください。
Z/OS における DB2 のセットアップ
データベース表を転送した後で、再編成が必要な表をまず判別します。
REORG チェックを実行してパフォーマンスを向上させます。
•
データベースの転送後に EJPSDBTC ジョブを実行します。このジョブには、DB2 の
チ ェ ッ ク お よ び JCR 、 Likeminds 、 フ ィ ー ド バ ッ ク の 各 デ ー タ ベ ー ス に 対 す る
RUNSTATS ユーティリティーの実行が含まれます。
48
WEBSPHERE PORTAL 7.0 TUNING GUIDE
•
DB2 データベースの REORG の詳細については、WebSphere Portal のインフォメーシ
ョン・センターにアクセスしてください。
REORG ジョブを作成して、WPSDBJCR データベースのすべての表スペースを再編成しま
す。
DB2 LUW で推奨されるデータベース保守
データベース属性のうち、DB2 が最適なパフォーマンスを発揮できるように使用する属性
は、データベースのカタログ統計と表内のデータの物理編成の 2 つです。カタログ統計は、
データベースの存続期間中、定期的に再計算する必要があります。特に転送フェーズなど
の大量のデータ変更 (挿入、更新、および削除) が行われる期間が終わった後に行う必要が
あります。これらの統計の計算に伴う激しい競合のため、この保守作業は、業務時間外、
要求が少ない時間帯、またはポータルがオフラインのときに実行するのが最善です。DB2 の
runstats コマンドは、表、索引、および列に関する詳細な統計情報を算出して記録するため
に使用されます。本書の環境では、2 つの手法を使用してこれらの統計を再計算しました。
推奨する形式は以下のようなものです。
49
WEBSPHERE PORTAL 7.0 TUNING GUIDE
db2 runstats on table tableschema.tablename on all columns with distribution on all columns and
sampled detailed indexes all allow write access
これらのオプションにより、オプティマイザーが複雑な SQL のための最適なアクセス・プ
ランを決定することができるようになります。
カタログ統計の再計算をするための、より簡単で便利な手法としては以下のものがありま
す。
db2 reorgchk update statistics on table all
このコマンドは、カタログ統計の一部を算出して記録するだけでなく、表の編成上の問題
を特定するために利用できるレポートも生成します。ただし、オプティマイザーが複雑な
SQL、特に JCR データベースの照会のための効率的なアクセス・プランを選択するには、
このコマンドによって生成される情報では不十分であるケースもありました。
reorgchk コマンドと同じように便利で、かつオプティマイザーにとって望ましい詳細な統
計情報が得られる手法が必要な場合には、以下のコマンドを使用します。
db2
-x
-r
"runstats.db2"
"select
rtrim(concat('runstats
on
table
',concat(rtrim(tabSchema),concat('.',concat(rtrim(tabname),' on all columns with distribution on all
columns and sampled detailed indexes all allow write access'))))) from syscat.tables where
type='T'"
db2 -v -f "runstats.db2"
最初のコマンドは、runstats.db2 というファイルを作成するために使用されます。このファ
イルには、すべての表のすべての runstats コマンドが記述されます。2 つ目のコマンドは、
db2 コマンド・プロセッサーを使用して、それらのコマンドを実行します。
どのテーブルに再編成するメリットが見込まれるかを判断するには、以下のコマンドを使
用します。
db2 reorgchk current statistics on table all > "reorgchk.txt"
再編成が必要な表には、以下のコマンドを使用します。
50
WEBSPHERE PORTAL 7.0 TUNING GUIDE
db2 reorg table tableschema.tablename
これにより、主キーに基づいて表が再編成されます。
データベース・サーバーで適切な数のディスクが使用されていることを確認する必要があ
ります。複数のディスクを使用することにより、データベース・エンジンのスループット
を向上させることができます。スループットは、データベース・ログをデータベースとは
別の物理装置上に分けて配置することでも向上します。
51
WEBSPHERE PORTAL 7.0 TUNING GUIDE
各 WebSphere Portal アプリケーション・サーバー・インスタンスのデータ・ソースとセッ
ション・マネージャーの両方に必要な接続数の合計よりも大きな値がデータベース・パラ
メーター MaxAppls に設定されていることを確認してください。MaxAppls の値が不十分な
場合は、Portal のログにエラー・メッセージが出力されます。
結果セットを計算するために一時表が必要となる複雑な SQL のパフォーマンスで効果を
得るには、TEMPORARY 表スペースに System Managed Storage (SMS) を使用するようにし
ます。これにより、バッファーの書き込み時間が短縮され、ディスク使用率が向上します。
データベースのパフォーマンスは、WebSphere Portal から良好なパフォーマンスを得る上
できわめて重要です。本書に記載されている保守のタスクとプラクティスは、実験環境に
おける WebSphere Portal のパフォーマンスと適切な運用のためにとって、きわめて重要な
ものであることがわかりました。実稼働環境では、追加のデータベース保守やチューニン
グが必要となる場合があります。DB2 の管理およびチューニングについての詳細は、DB2
のインフォメーション・センターを参照してください。
ORACLE データベース・サーバーのチューニング
WebSphere Portal V7.0 は、データベース・サーバーをコア機能として使用します。測定環
境では、Portal アプリケーションに Oracle データベース・サーバーを使用しました。LDAP
サーバーとして使用した IBM Tivoli Directory Server のリポジトリーは DB2 データベース
で構成しました。
Oracle Enterprise Edition Database の計画
Solaris プラットフォームの測定では、同様に、Oracle 10g R2 をデータベース・サーバーと
して使用しました。WebSphere Portal V7.0 は、データベース・ドメインの概念を使用して
おり、1 つのドメインに属している複数の表のグループを指定するか、あるいは、まった
く別個のデータベースを指定して、各ドメインに固有のデータを保管します。
Oracle の場合では、単一のデータベースを構築して、各ドメインのサポートに必要な表と
デ ー タ を 所 有 す る Oracle ユ ー ザ ー を 作 成 し ま し た 。 各 ド メ イ ン は 、 前 述 の
PortalDatabaseDomain に記載されています。基本ポータルの測定では、リリース・ドメイン
を 1 次データベースとして使用します。
適切に設計されたデータベースは、将来的に多くの手間を省き、データベースのパフォー
52
WEBSPHERE PORTAL 7.0 TUNING GUIDE
マンスを向上させることができます。十分な情報を得た上でデータベース設計を決定でき
るように、Oracle 管理者ガイドを参照されることをお勧めします。Oracle データベースに
実装した重要な選択事項を以下に示します。
•
I/O 競合を回避し、スループットを向上させるために、データベース・サーバーで適切
なディスク数が使用されていることを確認する必要があります。ストライピングされ
た 7 つのディスク上にデータベースを構築します。
•
ストレージ構造の管理を容易にし、最適なパフォーマンスを得るために、データベー
スで redo ログ、制御ファイルとともに Oracle Managed Files を使用します。
•
データベースのブロック・サイズ:8k
53
WEBSPHERE PORTAL 7.0 TUNING GUIDE
•
中規模程度の Portal (100,000 人の認証済みユーザー、180 個のインストール済みポー
トレットおよび 220 のページを含む) をサポートするために、以下の表スペースのサ
イジングが必要となりました。この規模では、一般的にデータベースの読み取り操作
による負荷が発生します。表スペースのサイジングと増加率を定期的に監視すること
をお勧めします。DBCA を使用して、以下の表スペース・サイズを含むデータベース
を作成しました。
o SYSAUX:800MB
o SYSTEM:800MB
o TEMP:800MB
o UNDOTBS:1024MB
o USERS:2048MB
•
redo ログ・グループ:各 500MB
AIX における Oracle のセットアップ
以下のセットアップを使用して、AIX に Oracle データベースを構成します。
•
Portal のデータベースを格納するファイル・システムを Enhanced Journal File System
(JFS2) に設定します。
•
データベース・ファイル・システムで Concurrent I/O (CIO) を使用可能にすることに
より、パフォーマンスが向上します。Oracle の始動に失敗する可能性があるため、Oracle
製品のファイル・システム (/u01) では CIO を有効化しないでください。
CIO を有効化するには、次のコマンドを使用してデータベース・ファイル・セットをマウ
ントします。
mount .o cio /u02
•
AIX の ユーザーあたりの最大プロセス数を 4096 に増やします。
デフォルトのユーザーあたりのプロセス数は 500 ですが、データベース・サーバーの場合、
この値では低すぎるため、本書の AIX 環境では 4096 に増やします。この値を増やすには、
次のように実行します。
54
WEBSPHERE PORTAL 7.0 TUNING GUIDE
chdev .l sys0 .a maxuproc=.4096.
•
AIX の非同期 I/O を有効化し、MinServer の値を 5 に増やします。
smitty aio .->Change/Show Characteristics of Async I/O .->MinServers = 5
•
また、AIX 用の Oracle インストール・ガイドの推奨事項に従って、oracle ユーザーの
プロファイルを次のように設定しました。
AIXTHREAD_SCOPE=S
Oracle Enterprise Edition データベースのパラメーター・チューニング
データベースのパフォーマンスは、WebSphere Portal から良好なパフォーマンスを得る上
できわめて重要です。alter system コマンドを使用して Oracle データベース・サーバーに
適用したチューニングを下記のリストに示します。実稼働環境では、追加のデータベース・
チューニングが必要となる場合があります。Oracle データベースのチューニングの詳細に
ついては、http://www.oracle.com/technology/documentation/database10g.html にアクセスし
て、「Oracle Performance Tuning Guide」を参照してください。
55
WEBSPHERE PORTAL 7.0 TUNING GUIDE
使用したコマンド:
Alter system set <parameter> scope=spfile;
表 12:Oracle データベースのチューニング
パラメーター
値
sessions
900
sga_target
1813M
pga_aggregate_target
604M
processes
750
open_cursors
1500
db_files
1024
推奨される ORACLE データベース保守
オプティマイザーの統計情報は、データベースおよびデータベース内のオブジェクトに関
するデータの集合です。これらの統計情報は、照会オプティマイザーが各 SQL ステートメ
ントの最適な実行計画を選択するために使用されます。データベース内のオブジェクトは、
常に変更されている可能性があるため、データベース・オブジェクトの情報が正確に反映
されるように、統計情報を定期的に更新する必要があります。特に転送フェーズなどの大
量のデータ変更 (挿入、更新、および削除) が行われる期間が終わった後に行う必要があり
ます。本書の環境では、以下のコマンドを使用してこれらの統計情報を再計算しました。
execute dbms_stats.gather_database_stats(dbms_stats.auto_sample_size,
method_opt=>'FOR ALL INDEXED COLUMNS SIZE AUTO',cascade=>TRUE);
データベースに関するその他の考慮事項
WebSphere Portal は、ユーザーに関する一部の情報をデータベース表内に保持します。ま
た、これらの表はユーザーの初回ログイン時に拡張されます。本書では、ユーザーによる
サイトへの初回ログイン時におけるパフォーマンスではなく、WebSphere Portal の定常状
態のパフォーマンスに関心があったため、すべてのユーザーが少なくとも一度はログイン
した後で、パフォーマンスの評価を行いました。
データベース・チューニングにおける最も重要な要素の一つに、バッファー・プールのサ
56
WEBSPHERE PORTAL 7.0 TUNING GUIDE
イジングがあります。データベースの物理読み取りと論理読み取りを評価して、できれば、
論理読み取り率が 95% 程度になるように、バッファー・プールのサイジングを行う必要が
あります。
57
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ディレクトリー・サーバーのチューニング
測定時には、ディレクトリー サーバーとして IBM Tivoli Directory Server バージョン 6.0 を
使用しました。これらの製品では、ユーザー情報を保管するためにデータベースを使用す
るため、本書の環境では DB2 Enterprise Server をデータベースとして使用しました。通常、
このデータベースは、ディレクトリー・サーバーと同一システム上に配置します。ユーザ
ーの作成、更新、または削除などが作業に含まれる場合、このデータベースに対して、上
記のデータベース保守が必要となる場合があります。
Solaris の基本ポータル・シナリオの測定で、ディレクトリー・サーバーに使用したチュー
ニング値を以下の表に示します。
設定方法:
以下の値は、ファイル /opt/IBM/ldap/V6.0/etc/SchemaV6.0/ibmslapd.conf にあ
ります。これらの値を変更した場合、LDAP サーバーを再始動する必要があります。
表 13: IDS のチューニング
パラメーター
値
Ibm-slapdACLCacheSize
250000
Ibm-slapdEntryCacheSize
250000
Ibm-slapdFilterCacheSize
250000
Ibm-slapdFilterCacheBypassLimit
7500
IBM Tivoli Directory Server は、データベース・サーバーとして IBM DB2 を使用します。デ
ータベースのインスタンス名および別名は IDSLDAP です。このデータベースに適用したチ
ューニングは以下のとおりです。
db2 “update db config for idsldap using dbheap 4800”
db2 “update db config for idsldap using num_ioservers 10”
db2 “update db config for idsldap using num_iocleaners 5”
db2 alter bufferpool LDAPBP size 3690
db2 alter bufferpool IBMDEFAULTBP size 88500
さらに、LDAP サーバーの CPU 使用率が高い場合は、以下の手順を使用して ldap データ
ベースの索引を作成することができます。
db2 connect to idsldap
58
WEBSPHERE PORTAL 7.0 TUNING GUIDE
db2 "create index givenname_ix2 on idsldap.givenname (givenname)"
db2 "create index displaname_ix2 on idsldap.displayname (displayname, eid)"
db2 "runstats on table idsldap.givenname with distribution and detailed indexes all"
db2 "runstats on table idsldap.displayname with distribution and detailed indexes all"
以下のサイトでは、索引の作成についてこれとは別の方法を紹介しています。
http://www-01.ibm.com/support/docview.wss?uid=swg21379931
59
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Web サーバーのチューニング
測定環境では、IBM HTTP Server 7.0 を使用しました。クラスターの構成および Solaris の
構成には、リモート Web サーバーを使用します。リモート Web サーバーのチューニング
については、
『クラスターのチューニング』セクションの『Web サーバーのチューニング』
を参照してください。このほかの構成ではすべて、WebSphere Portal のアプリケーション・
サーバーと同一システム上で稼働する Web サーバーを使用します。Web サーバーと Portal
のアプリケーション・サーバーが単一システム上で稼働している場合に、監視中に、シス
テムのプロセッサー・キャパシティーの不足が認められた場合には、それぞれのサーバー
を別個のシステムに分けて配置することを検討してください。Web サーバーに使用したチ
ューニングは以下のとおりです。
表 14: Web サーバーのチューニング
パラメーター
Windows
2003
追加情報
KeepAliveTimeout
Linux お
よ
び
UNIX
( 例 :AIX 、
z/Linux
など)
5
5
この値をスクリプトで定義されている思考時
間よりも小さくして、慎重にテストが行えるよ
うにします。各ユーザーがページを表示するた
びに新しい TCP 接続がオープンされること
を想 定しています 。ただし、稼 働環境では
KeepAliveTimeout の値を高くした方が効果的
です。タイムアウト値を高くすると、HTTP サ
ーバーのプロセス競合が増加する可能性があ
ります。HTTP プロセスが不足している場合
は、この値を低くします。
ThreadsPerChild
25
2000
MaxKeepAliveRequests
0
0
Windows で子あたりのスレッド数が多
いのは、HIS に対して別のプロセス・モ
デルが存在するためです。
0 を選択することにより、単一の TCP
接続での要求が無制限になります。
MaxRequestsPerChild
StartServers
Access logging
0
2
0
off
off
ThreadLimit
ServerLimit
25
180
N/A
MinSpareThreads
MaxSpareThreads
MaxClients
25
4500
4500
N/A
N/A
N/A
以下の構成行をコメント化して無効化
し
ま
し
た
:CustomLog
/usr/HTTPServer/logs/access_log
common
2000
MaxClient /ThreadsPerChild に設定しま
す。
MaxClients と同じ値に設定します。
さらに、実行中と使用可能な状態の Web サーバー プロセス数を監視できるように、
60
WEBSPHERE PORTAL 7.0 TUNING GUIDE
server-status モジュールも有効化しました。これにより、MaxClients パラメーターと
ThreadsPerChild パラメーターが適切にチューニングされます。
Pagebuilder シナリオでは、追加の Web サーバー・チューニングを行いました。詳細につい
ては、Pagebuilder のセクションを参照してください。
61
WEBSPHERE PORTAL 7.0 TUNING GUIDE
プラグインのチューニング
プラグインを使用することにより、IBM HTTP Server for WebSphere Application Server と
WebSphere Application Server の通信が可能になります。
以下のプラグイン・パラメーターを設定します。
•
. ConnectTimeout:60 (デフォルト値は 5)
正常に接続するまでプラグインが待機するように、ConnectTimeout を 60 秒に増やします。
•
. ServerIOTimeout:180 (デフォルト値は 60)
serverIOTimeout は、個々の読み取りまたは書き込み操作が戻るのを、プラグインが待機す
る時間を制限します。デフォルト値は 60 秒です。この値を 180 秒に増やして、ピーク負
荷時に大量のネットワーク・トラフィックを処理するようにします。
詳細および設定方法については、下記のサイトを参照してください。
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.
multiplatform.doc/info/ae/ae/rwsv_plugincfg.html
オペレーティング・システムのチューニング
いかなる高負荷環境でも、ネットワークを注意深く監視して、許容範囲の一定したパフォ
ーマンスが得られるようにする必要があります。以下の設定は、すべてのネットワーク・
パラメーターをこの値に設定することを意図しているわけではありません。ネットワーク
もまた、パフォーマンス環境およびボトルネック解決プロセスにおける 1 つの要素である
ということを読者にご理解いただくためのものです。
AIX
ネットワークのチューニング
測定環境のすべての AIX システムで、以下のネットワーク・チューニング・パラメーター
を変更しました。
62
WEBSPHERE PORTAL 7.0 TUNING GUIDE
表 15: AIX のネットワーク設定
パラメーター
値
tcp_sendspace
131072
tcp_recvspace
131072
udp_sendspace
65536
udp_recvspace
655360
somaxconn
10000
tcp_nodelayack
1
rfc1323
1
これらのパラメーターは、no コマンドを使用するか、smit によって設定できます。smit で
これらのパラメーターを変更するには、「パフォーマンスとリソースのスケジューリング
(Performance & Resource Scheduling)」→「カーネルとネットワーク・パラメーターのチュー
ニング (Tuning Kernel & Network Parameters)」→「ネットワーク・オプション・パラメ
ーターのチューニング (Tuning Network Option Parameters)」→「現在のパラメーターの変
更/表示 (Change/Show Current Parameters)」を選択します。変更を永続的にするために、
「現
在のパラメーターを次回ブートのために保存 (Save Current Parameters for Next Boot)」も選
択します。
このようなチューニング設定 (特に、tcp_sendspace と tcp_recvspace の値) により、ネッ
トワーク・バッファーに大量のメモリーが割り当てられます。そのため、システムのメモ
リー量が制限されている場合は、パフォーマンス上の問題が発生する可能性があります。
そのような場合には、これらのパラメーターの値を小さくすると、問題が解決することが
あります。AIX のネットワーク・パフォーマンス・チューニングの詳細については、以下の
リンクを参照してください。
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftungd/doc/prftungd
/interface_network_opts.htm および
http://www.ibm.com/developerworks/aix/library/au-aixoptimization-netperform3/index.html
63
WEBSPHERE PORTAL 7.0 TUNING GUIDE
LINUX
ネットワークのチューニング
Red Hat Linux および z/Linux (Suse Linux on System z) では、ファイル /etc/sysctl.conf に
以下の設定を追加して、次のコマンドを実行します:sysctl -p
現在の TCP パラメーターを確認するには、次のコマンドを実行します:sysctl -a | fgrep tcp
表 16:Linux のネットワーク設定
パラメーター
値
net.ipv4.ip_forward
0
net.ipv4.conf.default.rp_filter
1
net.ipv4.conf.default.accept_source_route
0
net.core.rmem_max
16777216
net.core.wmem_max
16777216
net.ipv4.tcp_rmem
4096 87380 16777216
net.ipv4.tcp_wmem
4096 65536 16777216
net.ipv4.tcp_fin_timeout
30
net.core.netdev_max_backlog
3000
net.core.somaxconn
10000
net.ipv4.tcp_keepalive_intvl
15
net.ipv4.tcp_keepalive_probes
5
zLinux における HiperSockets
HiperSockets は、System z の中央演算処理装置複合システムで高速な TCP/IP 接続を提供
するテクノロジーの一つです。HiperSockets は、異なる LPAR で稼働するサーバー間で、
物理ケーブル接続や外部ネットワーク接続を一切必要としません。代わりに、通信はプロ
セッサーのシステム・メモリーを介して行われるため、各サーバーは「内部の LAN」を形
成するように接続されます。
zLinux のオーサリング・ワークロードについては、HiperSockets を使用して、アプリケー
ション・サーバーの LPAR とデータベース・サーバーの LPAR 間で通信することを試みま
した。このような通信と 100 メガビットの交換イーサネットを使用した LPAR 間の通信と
で、パフォーマンス面の大きな違いは確認されませんでした。このワークロードでは、
64
WEBSPHERE PORTAL 7.0 TUNING GUIDE
HiperSockets のパフォーマンスの効果を発揮できるほどのネットワーク・トラフィックが
2 つのシステム間で発生しなかったと考えられます。
65
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Windows 2003
ネットワークのチューニング
regedit コマンドを使用して、下記のセクションに以下のレジストリー設定を行いました。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
以下の名前で、REG_DWORD を新規に作成します。
表 17: Windows のネットワーク設定
パラメーター
値
MaxFreeTcbs
dword:00011940
MaxHashTableSize
dword:0000ffff
MaxUserPort
dword:0000fffe
TcpTimedWaitDelay
dword:0000001e
TcpWindowSize
dword:0000ffff (65535)
Solaris
ネットワークのチューニング
Solaris では、ndd コマンドを使用して、以下の TCP レイヤー・パラメーターを設定しま
す。この設定は直ちに反映され、大容量環境におけるネットワーク・レイヤーのパフォー
マンスが向上します。Portal サーバーが稼働する Solaris 10 で以下の設定を使用します。
設定方法:ndd -set /dev/tcp <PARAMETER> <VALUE>
表 18: Solaris のネットワーク設定
パラメーター
値
tcp_time_wait_interval
60000
tcp_keepalive_interval
15000
tcp_fin_wait_2_flush_interval
67500
tcp_conn_req_max_q
16384
tcp_conn_req_max_q0
16384
tcp_xmit_hiwat
40000
66
WEBSPHERE PORTAL 7.0 TUNING GUIDE
tcp_recv_hiwat
40000
tcp_cwnd_max
2097152
tcp_ip_abort_interval
60000
tcp_rexmit_interval_initial
4000
tcp_rexmit_interval_max
10000
tcp_rexmit_interval_min
3000
tcp_max_buf
4194304
67
WEBSPHERE PORTAL 7.0 TUNING GUIDE
カーネルのチューニング
使用した Portal サーバーは Solaris 10 で稼働しています。Solaris 10 では、以下の projmod
コマンドを使用して、システム・パラメーターを設定します。変更を行ったら、これらの
変更を反映するためにログインし直す必要があります。現在の設定を確認するには cat
/etc/project を実行します。
projmod -s -K 'project.max-shm-memory=(privileged,4294967296,deny)' user.root
projmod -s -K 'project.max-shm-ids=(privileged,1024,deny)' user.root
projmod -s -K 'project.max-sem-ids=(privileged,1024,deny)' user.root
projmod -s -K 'process.max-sem-nsems=(privileged,4098,deny)' user.root
projmod -s -K 'process.max-sem-ops=(privileged,16384,deny)' user.root
projmod -s -K 'process.max-file-descriptor=(privileged,16384,deny)' user.root
Solaris の仮想化
Solaris の仮想化技術であるリソース管理機能やゾーン機能を使用することで、数百ものプ
ロセッサーを搭載した、最新かつ強力な T2 サーバーをより効率的に使用します。
実験環境では、プロセッサー・セットを使用して仮想プロセッサーを区画化しました。Solaris
のリソース・プールを使用することによって、複数のプロセッサーを 1 つのプールにグル
ープ化し、そのプールを Java プロセスにバインドできます。
実験を通じて、このシナリオでは 21 個の計算スレッドを 1 つの JVM にバインドすると
最も効率良く使用できることがわかりました。6 個の WebSphere Portal メンバーを使用し
て垂直クラスターを作成し、メンバーごとに Solaris のプロセッサー・セットにバインドし
ました。計算スレッド (および WebSphere Portal メンバー) の適切な数はアプリケーショ
ンによって異なりますが、4 ～ 6 個のメンバーを使用すれば、ほとんどの WebSphere Portal
アプリケーションで良好なパフォーマンスを得られるでしょう。
構成のセットアップに使用した Solaris コマンドは以下のとおりです。
1. pooladm -e
プール機能を有効にします。
68
WEBSPHERE PORTAL 7.0 TUNING GUIDE
2. pooladm -s
現在の動的構成と同じ内容の静的構成ファイルを作成します。
3. poolcfg -c 'create wp_pset1 (unit pset.min=20; unit pset.max =21)'
最小数に 20、最大数に 21 を指定して、wp_pset1 という名前のプロセッサー・セットを作
成します。各アプリケーション・サーバーの JVM に対して、プロセッサー・セットを 1 つ
ずつ、それぞれに固有の名前を指定して作成します。
4. poolcfg -c 'create pool wp_pool1'
69
WEBSPHERE PORTAL 7.0 TUNING GUIDE
wp_pool1 という名前のリソース・プールを作成します。前の手順で作成した各プロセッサ
ー・セットに対して、リソース・プールを 1 つずつ、それぞれに固有のプール名を指定し
て作成します。
5. poolcfg -c 'associate pool wp_pool1(pset wp_pset1)'
リソース・プールとプロセッサー・セットを関連付けます。この手順を、プロセッサー・
セットとリソース・プールのペアごとに実行します。
上記で使用したプロセッサー・セットとリソース・プールの名前は任意です。ただし条件
として、プロセッサー・セット名は、手順 5 のリソース・プール名と一致している必要が
あります。また、手順 9 で JVM をリソース・プールにバインドする際に、リソース・プ
ール名を使用する必要があります。
6. pooladm -c
構成を /etc/pooladm.conf にコミットします。
7. WebSphere Application Server 管理コンソールから Portal のクラスター・メンバーを始動
します。
8. 以下のコマンドを使用して、WebSphere Portal JVM のプロセス ID を特定します。
ps -ef | grep java
JVM ごとに個別のプロセス ID があります。
9. poolbind -p wp_pool1 <PortalPID>
このコマンドは、指定したプロセスをリソース・プールにバインドします。ポータルの各
JVM に対して、JVM プロセスごとに個別のリソース・プールを使用してこのコマンドを実
行します。WebSphere Portal を再始動した場合は、WebSphere Portal の新しいプロセス ID
を指定して、poolbind コマンドを実行する必要があります。ただし、手順 1 から 6 までは
繰り返す必要はありません。
これらのコマンドの詳細については、http://docs.sun.com にアクセスして、Solaris のドキ
70
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ュ メ ン ト ・ セ ッ ト に あ る 「 System Administration Guide: Solaris Containers-Resource
Management and Solaris Zones」を参照してください。
71
WEBSPHERE PORTAL 7.0 TUNING GUIDE
z/OS
WLM のセットアップ
z/OS では、WLM を使用することによって、計算リソースをシステム規模で効率的かつ効
果的に使用して、システムに定義されているパフォーマンスとサービスの目標を実現する
ことができます。
WebSphere Application Server のアドレス・スペースは WLM の開始済みタスク制御 (STC)
分類規則によって制御されます。STC は、開始、停止、ログ出力、およびアドレス・スペ
ースでの実行に対するリソース割り当ての目標を処理します。STC は、リスニング・ポー
トのサーバーに着信した作業要求は処理しません。これらのアドレス・スペースの目標は、
直ちに開始されるように高く設定する必要があります。
要求が WLM の作業マネージャーまたはキューに届き、直ちに配置されると、処理の責務
は STC から CB に切り替わります。サーバー内の WebSphere で処理される J2EE アプ
リケーションの作業は、CB サブシステムで制御されます。CB は、WLM 内の WebSphere の
単なるサブシステム名です。
WebSphere Application Server 用の WLM の構成は以下のとおりです。
1. CB 分類規則 - 重要度 1 および平均応答時間のパーセンタイル目標 90% で定義された
サービス・クラスが割り当てられた WAS および Portal のトランザクションが 0.3 秒で完
了するようにします。
2. STC 分類規則 - コントローラー・アドレス・スペースを SYSSTC サービス・クラスに
割り当てます。サーバント・アドレス・スペースおよび従属アドレス・スペースを、実行
速度目標 70% で定義されたサービス・クラスに割り当てます。
WebSphere Application Server の WLM ポリシーを z/OS で構成する方法の詳細については、
以下のリンクを参照してください。
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101740
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101754
72
WEBSPHERE PORTAL 7.0 TUNING GUIDE
HiperDispatch の有効化
HiperDispatch は IBM z10 サーバーで導入され、z/OS V1R7、z/OS V1R8、および z/OS V1R9
で (PTF を介して) 使用できます。HiperDispatch は、以下のことができるように設計され
ています。(1) プロセッサーのキャッシュ・ミスによる z10 のハードウェア・パフォーマ
ンスの低下を最小限に抑えます。(2) 任意の単一の論理プロセッサーに関連付けられた
CPU の 処 理 能 力 を 最 大 限 に し ま す 。 HiperDispatch は 、 IEAOPTxx の パ ラ メ ー タ ー
HIPERDISPATCH=YES を設定することで有効になります。
73
WEBSPHERE PORTAL 7.0 TUNING GUIDE
システムのチューニング
PARMLIB のメンバー BPXPRMxx は、以下のパラメーター値をチェックします。
表 19:z/OS システムのチューニング
パラメーター
値
追加情報
MAXPROCSYS
15000
同時にアクティブにできるプロセスの最大数は
15000 です。
MAXPROCUSER
15000
ユーザー (同一 UID) あたり、同時にアクティブにで
きるプロセスの最大数は 15000 です。
MAXUIDS
200
同時にアクティブにできる z/OS UNIX ユーザーの
最大数は 200 です。
MAXFILEPROC
65535
ユーザーあたり、オープン可能なファイルの最大数
は 65535 です。
MAXPTYS
800
許可される疑似ターミナル・セッションの最大数は
800 です。
MAXTHREADTASKS
5000
1 つのプロセス内で、同時にアクティブにできるス
レッド・タスクの最大数は 5000 です。
MAXTHREADS
10000
1 つのプロセス内で、同時にアクティブにできるス
レッドの最大数は 10000 です。
MAXMMAPAREA
40960
メモリー・マッピングに使用可能なページの最大数
は 40960 です。
MAXFILESIZE
無制限
MAXCORESIZE
4194304
MAXASSIZE
2147483647
ファイル・サイズは無制限です。
このサイズは TSO の領域サイズと同じです。デフ
ォルトでは、USS ID に最小限の値が事前定義されて
いますが、通常、WPS のような製品を使用する場合、
十分な値とはいえません。Java プロセスを生成に関
する問題を回避するには、このサイズを 214783647
に設定してください。
MAXCPUTIME
2147483647
CPU の処理時間を向上させます。
MAXSHAREPAGES
32768000
同時に使用可能な共有ストレージのページの最大数
は 32768000 です。
74
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ページ・ビルダー・テーマのチューニング
Portal 7 に付属しているデフォルトのテーマは、ページ・ビルダー・テーマと呼ばれ、クラ
イアント・サイド集約 (CSA) を使用できます。このセクションのチューニングはすべて、
Portal 7 のデフォルトの「ページ・ビルダー」テーマに対応しています。
ページ・ビルダー・テーマを使用する際、わたしたちはコンテンツのキャッシュに IBM HTTP
サーバーを使用しました。代わりにリバース・プロキシーを使用することもできます。こ
のセクションでは、HTTP サーバーまたはリバース・プロキシーを使用してコンテンツをキ
ャッシュする方法について説明します。
一般には、ポータル・サーバーとは異なる物理ハードウェア上のリバース・プロキシーま
たは HTTP サーバーを使用することがベスト・プラクティスです。
ページ・ビルダー・テーマに対して許容できるスループットおよび応答時間を得るには、
外部キャッシュを配置することをお勧めします。これにより、一部のコンテンツは、ポー
タル・サーバーまでアクセスせずにフェッチできます。
一般に、ページ・ビルダー・シナリオには、前のセクションで説明した基本ポータル・シ
ナリオで使用されたものと同じチューニングが使用されていました。同セクションでは、
テーマに依存しないチューニング設定について説明しています。チューニングにおける違
いを以下に示します。
CacheManagerService プロパティー
基本ポータルのチューニングで変更したパラメーターに加え、CacheManagerService プロパ
ティーで次の値を指定します。
75
WEBSPHERE PORTAL 7.0 TUNING GUIDE
表 20: デフォルトの Portal 7 ページ・ビルダー・テーマ用の CacheManager サービス設定
パラメーター
使用する設定
cacheinstance.com.ibm.wps.spa.parser.theme.
2003
FirstLevelThemeParserCache.size
cacheinstance.com.ibm.wps.resolver.data.cache.
2003
FirstLevelDataSourceCache.size
cacheinstance.com.ibm.wps.resolver.data.cache.
8000
DataSourceCache.size
cacheinstance.com.ibm.wps.spa.PageTypeCache.enabled
true
cacheinstance.com.ibm.wps.spa.PageTypeCache.
false
supportsDependencies
cacheinstance.com.ibm.wps.spa.PageTypeCache.transactionaware
false
cacheinstance.com.ibm.wps.spa.PageTypeCache.shared
false
cacheinstance.com.ibm.wps.spa.PageTypeCache.size
5000
cacheinstance.com.ibm.wps.spa.PageTypeCache.lifetime
86400
Internet Explorer でブラウザー・キャッシュが適切に機能していることの確認
デフォルトで、WebSphere Portal はさまざまなバージョンの Internet Explorer に「vary」
HTTP ヘッダーを送信します。Internet Explorer は、
「vary」HTTP ヘッダーが送信された場
合、効果的にその応答をキャッシュできません。「vary」ヘッダーを IE に送信しないよう
WebSphere Portal を構成するには、以下の手順を実行します。
1. 管理者として WebSphere Portal にログインします。
2. 「管理 (Administration)」→「ポータルの設定 (Portal Settings)」→「サポートされている
クライアント (Supported Clients)」にナビゲートします。
3. 「.*MSIE 7.0.* (Internet Explorer 7)」を選択し、「選択されたクライアントの編集 (Edit
selected client)」をクリックします。
4.「ケイパビリティー (Capabilities)」フィールドで「CACHE_VARY」を選択し、
「削除 (Delete)」
→「OK」をクリックします。
5. 「サポートされているクライアント (Supported Clients)」にリストされている他のバージ
ョンの Internet Explorer についてもこれを繰り返します。「CACHE_VARY」がリストされて
いる場合は、これを削除します。
76
WEBSPHERE PORTAL 7.0 TUNING GUIDE
リダイレクトの削減
リダイレクトを回避すると、頻繁な要求によるオーバーヘッドが減少してパフォーマンス
が向上します。リダイレクトを回避するには以下の手順を実行します。
1) ベース URL を有効にします。
設定方法: ベース URL を有効にするには、テーマでベース URL を有効にする方法に関す
るセクションを参照してください。
2) ホーム・ページでのリダイレクトを回避します。
77
WEBSPHERE PORTAL 7.0 TUNING GUIDE
設定方法:
JSP ファイル
(/PortalRoot/theme\wp.mashup.cc.theme\installedApps\wp.mashup.cc.theme.ear\PageBuilder2.
war\themes\html\PageBuilder2\bannerCommonActions.jsp) の内容を以下のように変更しま
す。
ファイルの以下の部分の強調表示されたフィールドを変更します。変更前:
<portal-logic:if loggedIn="no">
# <portal-navigation:urlGeneration allowRelativeURL="true"
contentNode="wps.content.root" home="protected" > <a
href='<%wpsURL.write(escapeXmlWriter); %>' ><portal-fmt:text
key="link.login" bundle="nls.engine"/></a> </portalnavigation:urlGeneration> </li> </portal-logic:if>
変更後:
<portal-logic:if loggedIn="no">
# <portal-navigation:urlGeneration allowRelativeURL="true"
contentNode="wps.Login" home="public" > <a href='<%
wpsURL.write(escapeXmlWriter); %>' ><portal-fmt:text key="link.login"
bundle="nls.engine"/></a> </portal-navigation:urlGeneration> </li>
</portal-logic:if>
カスタムのログイン・ページを使用している場合は、contentNode がログイン・ページの固
有の名前と一致していることを確認します。前の例では、これは wps.Login です。ログイ
ン・ページの固有の名前は、
「ポータル管理 (Portal Administration)」→「ページの管理 (Manage
Pages)」で確認できます。ログイン・ページは通常「コンテンツ・ルート (Content Root)」
→「非表示ページ (Hidden Pages)」にあります。
WebDAV リソースの提供
デフォルトのページ・ビルダー・テーマでは、多くのリソースは WebDAV ストレージから
取得されます。認証済みのユーザーと認証されていないユーザーの両方に対し、同じ URL
を安全に使用できます。この機能を有効にするには、WAS 管理コンソールで以下の手順を
実行します。
78
WEBSPHERE PORTAL 7.0 TUNING GUIDE
1. 「サーバー (Servers)」→「サーバー・タイプ (Server Types)」→「WebSphere アプリケ
ーション・サーバー (WebSphere application servers)」→「WebSphere_Portal」にナビゲート
します。
2. 「セキュリティー・ドメイン (Security Domain)」をクリックします。
3. 「Web および SIP セキュリティー (Web and SIP security)」を展開します。
4. 「一般設定 (General Settings)」をクリックします。
5. 「無保護の URI にアクセするするときに使用可能な認証データを使用する (Use available
authentication data when an unprotected URI is accessed)」にチェック・マークを付けます。
6. 保存します。
サーバー・サイド・モードでのマッシュアップ・マルチパート・チューニング
ページ・ビルダー・テーマのサーバー・サイド・モードのウィジェットは多くはなく、マ
ルチパート・ダウンロードを無効にしてパフォーマンスを向上させることができます。
79
WEBSPHERE PORTAL 7.0 TUNING GUIDE
設定方法: WebSphere 管理コンソールで、
「サーバー (Servers)」→「リソース (Resources)」
→「リソース環境 (Resource Environment)」→「リソース環境プロバイダー (Resource
Environment Providers)」→「WP_CommonComponentConfigService」にナビゲートします。
表 21: マッシュアップ・マルチパート・モード設定
デフォルト値
値
com.ibm.mashups.multipart.enabled
True
False
com.ibm.mashups.multipart.correlatehosts
True
False
ページおよびポートレットでのパーソナライゼーション可視性ルールの無効化
ポータルのインストールで個別のページおよびポートレットにパーソナライゼーション
(PZN) ルールを使用していない場合、ページおよびポートレットのパーソナライゼーショ
ン・ルールの処理を無効にすることによって、大幅にパフォーマンスを向上させることが
できます。
設定方法:
./ConfigEngine.sh action-disable-page-as-extension-node-wp.dynamicui.config
-DPageUniqueName=wps.content.root
デフォルトで PZN 変換は wps.content.root に登録されます。お客様がこれを手動で別のペ
ージに変更した場合、wps.content.root の代わりに PZN 変換が登録されている場所を示す
固有の名前を使用する必要があります。
キャッシング・プロキシーの使用
どのテーマでも、大きなリソースはエンド・ユーザーのパフォーマンスに重大な影響を与
える可能性があります。このようなパフォーマンスの影響は、アプリケーション・サーバ
ー外でリソースの圧縮またはキャッシュ、あるいはその両方を実行することにより、最小
限に抑えることができます。
キャッシュには、リバース・プロキシーを使用する方法と、HTTP サーバーでキャッシュを
有効にする方法の 2 つの選択肢があります。このセクションでは、この 2 つの選択肢に
ついて説明します。
HTTP サーバーはポータルとは別のサーバーに配置し、HTTP サーバー上のメモリー内キャ
80
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ッシュを使用して、リバース・プロキシーは使用しないようにすることをお勧めします。
その他の構成も可能ですが、layerLoader.jsp などの大きなリソースは確実にキャッシュおよ
び圧縮されるようにしてください。ポータルでコンテンツを圧縮し、HTTP サーバーでこれ
をキャッシュすることで、パフォーマンスが大幅に向上することが確認されています。
キャッシュにおいて HTTP サーバー上でリバース・プロキシーを使用することの利点は、
使用されるトポロジーによって異なります。一般に、アプリケーション・サーバーが実行
されていないサーバーでキャッシュが実行されるようにすることが最善の方法です。した
がって、HTTP サーバーがアプリケーション・サーバーと同じサーバー上にある場合は、別
のサーバー上のキャッシング・リバース・プロキシーを使用することをお勧めします。
81
WEBSPHERE PORTAL 7.0 TUNING GUIDE
リバース・プロキシーを使用することの欠点は、このプロキシーがコンテンツを圧縮およ
びキャッシュして、Internet Explorer に「Vary」ヘッダーを送信しないように構成すること
が困難なことです。
HTTP サーバーでのキャッシュにおいて、メモリー内キャッシュを使用することの利点は、
ディスク・キャッシュより高速であることです。欠点は、メモリー内キャッシュの方がよ
り多くのメインメモリーを使用する可能性があることです。
HTTP サーバーでのキャッシュの有効化
HTTP サーバーでのキャッシュには、ディスク・キャッシュとメモリー内キャッシュの 2 つ
の方法があります。高速なのはメモリー内キャッシュです。ただし、ディスク・キャッシ
ュは Windows では機能しません。Windows での唯一の選択肢はメモリー内キャッシュです。
次の値を HTTP サーバーの httpd.conf ファイルに設定します。
メモリー内キャッシュには、以下を使用します。
LoadModule cache_module modules/mod_cache.so
<IfModule mod_cache.c>
LoadModule mem_cache_module modules/mod_mem_cache.so
<IfModule mod_mem_cache.c>
CacheEnable mem /
MCacheSize 102400
MCacheMaxObjectCount 10000
MCacheMinObjectSize 1
MCacheMaxStreamingBuffer 6291456
MCacheMaxObjectSize 6291456
</IfModule>
</IfModule>
ディスク・キャッシュ (Windows では使用不可) には、以下を使用します。
LoadModule cache_module modules/mod_cache.so
<IfModule mod_cache.c>
82
WEBSPHERE PORTAL 7.0 TUNING GUIDE
LoadModule disk_cache_module modules/mod_disk_cache.so
<IfModule mod_disk_cache.c>
# make sure the path below exists and the http server group has access to it
CacheRoot /usr/IBMIHS7/diskCachetemp/
CacheEnable disk /
CacheDirLevels 5
CacheDirLength 3
CacheMaxFileSize 10000000
</IfModule>
</IfModule>
83
WEBSPHERE PORTAL 7.0 TUNING GUIDE
必ずディスク・キャッシュまたはメモリー内キャッシュのいずれかを選択し、両方を選択
しないようにしてください。キャッシング・リバース・プロキシーを使用する場合、HTTP サ
ーバーでのキャッシュは必要ありません。
Unix で HTTP メモリー内サーバー・キャッシュを使用する場合は、次の設定を使用して基
本ポータルの HTTP サーバー設定で説明した設定をオーバーライドします。Unix ベースの
HTTP サーバーは、各プロセスで情報をキャッシュします。次の設定により、プロセス数が
削減され、プロセスあたりのスレッド数が増加します。これにより、HTTP サーバー・プロ
セスで必要となる合計メモリー量が削減されます。
表 22: HTTP キャッシュ用の HTTP サーバー設定
パラメーター
AIX POWER5
追加情報
ThreadsPerChild
150
Windows で子あたりのスレッド数が多いのは、HIS に
対して別のプロセス・モデルが存在するためです。
StartServers
1
ThreadLimit
150
ServerLimit
25
これは、MaxClient /ThreadsPerChild に設定します。
適切な HTTP ヘッダーを設定するためのその他の HTTP サーバー設定については、「Web
サーバーのチューニング」を参照してください。これらの設定は、HTTP サーバーがキャッ
シュ用に構成されているかどうかにかかわらず使用されます。
リバース・プロキシー・サーバーでのキャッシュの有効化
HTTP サーバーでのキャッシュの代わりに、リバース・プロキシーでキャッシュすることが
できます。わたしたちは IBM Edge Server バージョン 6.0.2 にフィックスを適用して使用し
ました。
この Edge Server では、layerLoader.jsp を圧縮およびキャッシュすることはできませんでし
た。したがって、Edge Server で圧縮を行って満足な結果を得ることはできませんでした。
Portal でコンテンツを圧縮し、HTTP サーバーでキャッシュ・ヘッダーを追加し、Edge
Server で結果をキャッシュすることで、よい結果は得られませんでした。
わたしたちが使用したバージョンの Edge Server で圧縮を行う際には、リバース・プロキ
シーが応答を圧縮すると、Edge Server が「Vary」HTTP 応答ヘッダーを送信するという、
84
WEBSPHERE PORTAL 7.0 TUNING GUIDE
もう 1 つの問題があります。Internet Explorer (IE) が「Vary」ヘッダーと共に応答を受信す
る場合、IE は次に項目が要求されたときにその項目が変更されているかどうかを必ず確認
します。これは望ましい動作ではありません。サーバーにメッセージを送信せずにブラウ
ザー・キャッシュ内のバージョンを使用するのではなく、不必要な要求が送信されること
になるからです。IE に送信される圧縮された応答に「Vary」ヘッダーが含まれないように
してください。
ページ・ビルダー・テーマでリバース・プロキシーを使用するためにリバース・プロキシ
ーの ibmproxy.conf ファイルで指定する設定およびチューニングを次に示します。これらの
設定により、応答のキャッシュが可能となりますが、ポータルで応答を圧縮することも可
能となります。
85
WEBSPHERE PORTAL 7.0 TUNING GUIDE
表 23: リバース・プロキシー設定
パラメーター
使用する設定
追加情報
Proxy /wps/* http://{server-name}/wps/*
/wps 用プロキシー
Proxy /wps_semanticTag*
/wps_semanticTag 用 プ ロ キ
http://{servername}/wps_semanticTag*
シー
Proxy /searchfeed* http://{server-name}/searchfeed*
/searchfeed 用プロキシー
Proxy /portal_dojo/* http://{server-name}/portal_dojo/*
/portal_dojo 用プロキシー
Proxy /PageBuilder2/* http://{server-name}/PageBuilder2/*
/PageBuilder2 用プロキシー
Proxy /mccenabler/* http://{server-name}/mccenabler/*
/mccenabler 用プロキシー
ConnThreads
15
ServerConnPool
on
MaxSocketPerServer
20
CacheTimeMargin
5 秒
CacheFileSizeLimit
2M
flexibleSocks
off
LimitRequestFieldSize
16384
Web サーバーのチューニング
次の設定により、HTTP サーバーは要求に適切なキャッシュ・ヘッダーを追加できるように
なり、HTTP サーバーでのキャッシュを可能にすることができます。
# uncommented the following to enable statics to be cached
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
# from http://www.contentwithstyle.co.uk/blog/147 avoid gzip bug in IE 6
BrowserMatch ^Mozilla/4\.[0678] no-gzip
BrowserMatch \bMSIE\s7 !no-gzip !gzip-only-text/html
AllowEncodedSlashes On
ExpiresActive On
ExpiresByType text/javascript "access plus 5 days"
# note that the following max-age=86400 are just an example.
86
WEBSPHERE PORTAL 7.0 TUNING GUIDE
#A lower value might be more appropriate for your site
<LocationMatch "\.(gif|jpeg|jpg|png|ico|jsp|css|js|swf|json)$">
header set Cache-Control "public,max-age=86400"
</LocationMatch>
<LocationMatch "/mccenabler/js/com/ibm/mm/livetext/.*\.cfg">
header set Cache-Control "public,max-age=86400"
</LocationMatch>
<LocationMatch "/mccbuilder/widget-catalog/.*\.xml">
header set Cache-Control "public,max-age=86400"
</LocationMatch>
87
WEBSPHERE PORTAL 7.0 TUNING GUIDE
大量ページのチューニング
基本ポータル・シナリオに基づいた「大量ページ・シナリオ」では、ユーザーに大量のペ
ージを表示することの効果を評価します。WebSphere V7.0 以降では、ページ数が 2,500 以
上の場合、サイトに大量のページがあると見なされます。
大量ページ・シナリオは、基本ポータル・シナリオに基づいているため、基本ポータル・
シナリオに使用したものと同じチューニングが適用されます。チューニングにおける違い
を以下に示します。
DB2 データベースのチューニング
わたしたちがリリース・データベースに適用したチューニングは以下のとおりです。
表 24:大量ページ用の DB2 データベース設定
リリース DB
パラメーター
使用する設定
dbheap
4800
applheapsz
4096
logbufsz
256
num_IOServers
8
num_IOCleaners
8
設定方法: DB2 サーバーで以下のコマンドを実行します。
db2 “update db cfg for release using dbheap 4800”
db2 “update db cfg for release using applheapsz 4096”
db2 “update db cfg for release using logbufsz 256”
db2 “update db cfg for release using app_ctl_heap_sz 4096”
db2 “update db cfg for release using num_IOServers 8”
db2 “update db cfg for release using num_IOCleaners 8”
88
WEBSPHERE PORTAL 7.0 TUNING GUIDE
キャッシュ・マネージャー・サービス
表 25: 大量ページ用のキャッシュ・マネージャー・サービス設定
パラメーター
使用する設定
com.ibm.wps.datastore.pageinstance.OIDCache.size
10000
com.ibm.wps.datastore.pageinstance.OIDCache.lifetime
28800
com.ibm.wps.datastore.pageinstance.DerivationCache.size
10000
com.ibm.wps.datastore.pageinstance.DerivationCache.lifetime
28800
89
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Web コンテンツ管理のチューニング
一般に、Web コンテンツ管理 (WCM) シナリオでは、基本ポータル・シナリオで使用され
たものと同じチューニングが使用されていました。主な違いはキャッシュ・チューニング
設定です。WCM では、異なるキャッシュ・チューニング・セットでの調整が必要なポータ
ル・アクセス制御コンポーネントが要求されることが多く、チューニング可能なオブジェ
クト・キャッシュのセットが内部に用意されています。キャッシュ・チューニングに加え
て、WCM では基本ポータル・シナリオより多くの Web コンテナーおよび JCR データ・
ソースを必要とする場合があります。オーサリング・ワークロードが大きい場合は、これ
が特に顕著です。チューニングにおける違いを以下に示します。
アプリケーション・サーバーのチューニング
•
Web コンテナー・スレッド・プール - 最小値と最大値の両方に 60 スレッドの値を使
用しました。
•
データ・ソース接続プール - 次の値を使用しました。
データ・ソース
JCRDB
レンダリング値 (最
複合レンダリング値
オ ー サ リ ン グ /API
小/最大)
(最小/最大)
値 (最小/最大)
10/150
10/150
10/150
90
WEBSPHERE PORTAL 7.0 TUNING GUIDE
WebSphere Portal サービスのプロパティー
キャッシュ・マネージャー・サービス
ポ ー タ ル ・ キ ャ ッ シ ュ ・ サ イ ズ
- 基 本 ポ ー タ ル の 値 を 無 視 し 、
CacheManagerService.properties に次の値を設定します。
表 26:WCM 用のキャッシュ・マネージャー・サービス設定
CacheManagerService.properties ファイル
パラメーター
値
cacheinstance.com.ibm.workplace.searchmenu.helper.
5000
SearchMenuCacheHelper.size
cacheinstance.com.ibm.wps.ac.AccessControlUserContextCache.
10800
lifetime
cacheinstance.com.ibm.wps.ac.ApplicationRoleChildrenCache.size
500
cacheinstance.com.ibm.wps.ac.ApplicationRoleDescriptorCache.size
500
cacheinstance.com.ibm.wps.ac.ApplicationRoleOIDCache.size
500
cacheinstance.com.ibm.wps.ac.ApplicationRolesForPrincipalCache.size
12500
cacheinstance.com.ibm.wps.ac.ChildEntitlementsCache.size
500
cacheinstance.com.ibm.wps.ac.ContainedRolesCache.size
500
cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.
500
APPLICATION_ROLE.size
cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.size
500
cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.VIRTUAL.size
500
cacheinstance.com.ibm.wps.ac.ExternalOIDCache.size
12000
cacheinstance.com.ibm.wps.ac.groupmanagement.NestedGroupCache.size
1200
cacheinstance.com.ibm.wps.ac.ProtectedResourceCache.size
12500
cacheinstance.com.ibm.wps.ac.RolesCache.size
7500
cacheinstance.com.ibm.wps.datastore.pageinstance.DerivationCache.size
250
cacheinstance.com.ibm.wps.datastore.pageinstance.OIDCache.size
250
cacheinstance.com.ibm.wps.model.content.impl.ResourceCache.
14400
lifetime
cacheinstance.com.ibm.wps.model.content.impl.ResourceCache.size
500
cacheinstance.com.ibm.wps.model.content.impl.TopologyCache.size
500
91
WEBSPHERE PORTAL 7.0 TUNING GUIDE
cacheinstance.com.ibm.wps.model.factory.ContentModelCache.live.size
5000
cacheinstance.com.ibm.wps.policy.services.PolicyCacheManager.lifetime
28800
cacheinstance.com.ibm.wps.services.cache.cachedstate.CachedStateServiceSessionBound.cache.s
250
ize
cacheinstance.com.ibm.wps.pe.portletentity.firstLevelCacheSize
0
cacheinstance.com.ibm.wps.pe.portletentitycounter.firstLevelCacheSize
0
cacheinstance.com.ibm.wps.pe.portletregistry.firstLevelCacheSize
0
cacheinstance.com.ibm.wps.pe.portletmodel.portletdefinition.firstLevelCacheSize
0
cacheinstance.com.ibm.wps.pe.contenttypes.nocharset.firstLevelCacheSize
0
cacheinstance.com.ibm.wps.pe.contenttypes.result.firstLevelCacheSize
0
cacheinstance.com.ibm.wps.contentmapping.ContentMappingInfoCache.firstLevelCacheSize
0
cacheinstance.DigestCache.cache.size
20000
アクセス制御データ管理サービス
表 27: WCM 用のアクセス制御データ管理サービス設定
AccessControlDataManagementService.properties ファイル
パラメーター
使用する値
accessControlDataManagement.acucIgnoreRes
NULL
ourceTypes
ナビゲーション・サービス
ポータル・ナビゲーター・サービス – これを無効のままにすることにより、無名ページで
のパフォーマンスの向上を実現できます。ただし、無名ページで (IBM レガシー・ポートレ
ット API に基づく) 古い Web コンテンツ・ビューアー・ポートレットを使用している場
合は、共用セッションを有効にしておく必要があります。
表 28: WCM 用のナビゲーション・サービス設定
NavigatorService.properties ファイル
パラメーター
デフォルト値
使用する値
定義
public.session
false
false
匿名ユーザーがセッ
ションを持つかどう
かを制御します。
92
WEBSPHERE PORTAL 7.0 TUNING GUIDE
パーソナライゼーション・サービス
複合レンダリング・シナリオでは、次のチューニング・パラメーターを設定することによ
り、パフォーマンスを向上させることができます。
93
WEBSPHERE PORTAL 7.0 TUNING GUIDE
表 29: WCM 複合レンダリング用のパーソナライゼーション・サービス設定
PersonalizationService.properties
パラメーター
使用する値
bypassWebContentLinks
1
rulesengine.cache.timeout
900
WCM オブジェクト・キャッシュ
表 30: WCM オブジェクト・キャッシュ設定
WCM オブジェクト・キャッシュ
キャッシュ名
使用する値
abspath
8000
abspathreverse
8000
processing
10000
session
6000
strategy
8000
summary
4000
設定方法: WAS 管理コンソールにログインし、
「リソース (Resources)」→「キャッシュ・
インスタンス (Cache instances)」→「オブジェクト・キャッシュ・インスタンス (Object cache
instances)」にナビゲートします。
これらのキャッシュの詳細な説明については、この文書の「Web Content Management キャ
ッシュ」セクションを参照してください。
WCM 構成サービス
ユーザー・キャッシュの有効化
以下の場所で WCMConfigService.properties ファイルを見つけます。
<wp_profile>/PortalServer/wcm/shared/app/config/wcmservices
user.cache=true に設定します。
94
WEBSPHERE PORTAL 7.0 TUNING GUIDE
subscriberOnly 設定の有効化 (レンダリング用のみ)
deployment.subscriberOnly=true に設定します。
subscriberOnly 設定を環境に対して有効にするのは、その環境にサブスクライブし、かつそ
の環境からシンジケートしない場合のみにする必要があります。この設定は実稼働環境で
有効にすることをお勧めします。
95
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Web コンテンツ・ビューアー・ポートレットのキャッシュ
新しい Web コンテンツ・ビューアー・ポートレット (JSR 286) バージョンには、ポートレ
ットで生成された HTML コンテンツ (ポートレット・フラグメント) のキャッシュを可能
にする機能が追加されています。WCM オブジェクト・キャッシュに加え、このキャッシュ
を使用できます。このキャッシュを有効にすることによって、特に Web コンテンツ・ビュ
ーアー・ポートレットで個人的ではないコンテンツを表示している場合は、大幅にパフォ
ーマンスを向上させることができます。このキャッシュを有効にするには、以下の手順を
実行します。
1. WAS 管理コンソールの「サーバー (Servers)」→「アプリケーション・サーバー (Application
Servers)」→「WebSphere Portal」→「Web コンテナーの設定 (Web Container Settings)」→
「Web コンテナー (Web Container)」で、サーブレット・キャッシュを有効にします。
2. WAS 管理コンソールの「サーバー (Servers)」→「アプリケーション・サーバー (Application
Servers)」→「WebSphere Portal」→「ポートレット・コンテナー (Portlet Container)」で、
ポートレット・フラグメント・キャッシュを有効にします。
3. Portal サーバーを再始動します。
4. 管理者としてポータルにログインし、ポートレット・キャッシュを有効にするレンダリ
ング・ポートレットを含むページにナビゲートします。
5. ポートレットの右上隅にあるドロップダウンから「構成 (Configure)」または「共有設定
の編集 (Edit Shared Settings)」を選択します。構成モードで設定すると、その設定はこのポ
ートレットのすべてのインスタンスに適用され、編集モードで設定すると、その設定は 1
つのインスタンスのみに適用されます。
図 1 ポートレット設定のスクリーン・ショット
96
WEBSPHERE PORTAL 7.0 TUNING GUIDE
6. 「ポートレット設定 (Portlet Settings)」→「ポートレット・キャッシュ・オプション (Portlet
Cache Options)」で、ポートレットに適したキャッシュの有効範囲と有効期限の設定を選択
します。
Cache scope :
Shared cache across users : このタイプのキャッシュは、ユーザー間でレンダリング・ポー
トレットの出力をキャッシュするときに最大のパフォーマンスの向上を実現します。この
キャッシュの有効範囲は、個人的ではない Web コンテンツをレンダリングするレンダリン
グ・ポートレットにのみ使用されます。
97
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Non shared cache for a single user : このタイプのキャッシュは、パフォーマンスが大きく
向上することはありませんが、レンダリング・ポートレットにより表示される個人的な Web
コンテンツのキャッシュを可能にします。
Expiration :
Cache always expires :
共有ポートレット・キャッシュでも専用ポートレット・キャッシュ
でも、コンテンツがキャッシュされることはありません。すなわち、この設定によりキャ
ッシュは無効となります。
Cache never expires :
共有ポートレット・キャッシュでも専用ポートレット・キャッシュ
でも、無期限にコンテンツを格納できます。
Cache expires after this many seconds : 共有ポートレット・キャッシュでも専用ポートレッ
ト・キャッシュでも、指定された秒数だけコンテンツが格納されます。
新しい WCM ポートレット・キャッシュの詳細については、次の
URL
を
参
照
し
て
く
だ
さ
い
。
http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Caching_with_the_Web_Content_Viewer_%28JSR_2
86%29_Portlet_
WCM コンテンツ・ビューアー・ポートレット・キャッシュの監視
キャッシュを監視して、適切に機能していることを確認できます。WebSphere Application
Server には、キャッシュの監視を可能にするキャッシュ・モニター・アプリケーションが
付属しています。この他に、さらにバグが修正され、より多くの機能がある拡張キャッシ
ュ・モニターがあります。次の手順に従って、WCM コンテンツ・ビューアー・ポートレッ
ト・キャッシュのコンテンツを表示します。
1. キャッシュ・モニターをインストールまたは更新します。この方法については、
http://www.ibm.com/developerworks/websphere/downloads/cache_monitor.html を参照してく
ださい。
2. キャッシュ・モニター・アプリケーションにアクセスするには、管理者アカウントにこ
のアプリケーションへのアクセス権限を付与する必要があります。WAS 管理コンソールに
ログインし、
「アプリケーション (Applications)」→「アプリケーション・タイプ (Application
Types)」→「 WebSphere エンタープライズ・アプリケーション (WebSphere enterprise
98
WEBSPHERE PORTAL 7.0 TUNING GUIDE
applications)」→「動的キャッシュ･モニター (Dynamic Cache Monitor)」→「セキュリティー・
ロールとユーザー/グループのマッピング (Security role to user/group mapping)」にナビゲー
トします。「管理者」を選択し「ユーザーのマップ (Map Users)」をクリックします。適切
なユーザー・アカウントを検索し、これを「選択済み (selected)」ボックスに追加します。
「OK」→「保存 (Save)」をクリックします。
3. キ ャ ッ シ ュ ・ モ ニ タ ー ・ ア プ リ ケ ー シ ョ ン に ロ グ イ ン し ま す 。 URL は 、
http://myserver.com:<port>/cachemonitor のようになります。
4. 「baseCache」を選択し、「OK」をクリックします。
5. この時点で、キャッシュが有効なすべての WCM コンテンツ・ビューアー JSR 286 ポー
トレットは、このキャッシュへのエントリーを追加する必要があります。
99
WEBSPHERE PORTAL 7.0 TUNING GUIDE
6. キャッシュのコンテンツを表示するには、左側のメニューで「キャッシュ・コンテンツ
(Cache Content)」リンクをクリックします。
キャッシュのコンテンツを表示する他、キャッシュ・モニター・アプリケーションを使用
して、キャッシュ統計の表示、個々のキャッシュ・エントリーの無効化、およびキャッシ
ュ・コンテンツの比較を行うこともできます。
JCR テキスト検索
icm.properties - jcr textsearch の無効化
測定の間、テキストの索引付けは無効にします。テキストの索引付けは定期的に行われ、
新しいコンテンツがテキストの索引に追加されます。ただし、索引付けの間隔は、負荷の
停滞期と同期していません。その結果、パフォーマンスの測定中にテキストの索引付けを
実行した場合、測定の信頼性および再現性を低下させる可能性が高くなります。
実稼働環境ではテキストの索引付けを無効にすることはお勧めしません。これは、無効に
すると新しいコンテンツはテキストの索引に追加されず、検索結果には現れないためです。
テキストの索引付けを無効にする場合、icm.properties ファイルで jcr.textsearch.enabled プ
ロパティーの値を false に設定することにより無効にすることができます。このファイルは、
<wp_profile>/PortalServer/jcr/lib/com/ibm/icm ディレクトリーにあります。
DB2 のチューニング (オーサリング環境)
マルチプラットフォーム (LUW)
基本ポータル・シナリオの DB2 のチューニングのテストで、JCR データベースへの次の
ようなチューニングにより、環境内の DB2 の CPU およびディスク I/O の負荷が大幅に
低減されることがわかりました。
オーサリング・シナリオで、最初に IBMDEFAULTP および ICMLSMAINBP32 バッファー・
プールのサイズを変更する必要があることがわかりました。これは、起動時に DB2 がこれ
らのサイズ変更を十分な速さで行うことができず、シナリオの初期の段階で矛盾した結果
が生じるためでした。また、実行時に大量のデータベース・ファイル・ハンドルが開閉さ
れ、ディスク I/O にストレスを加え、JCR データベース用に開くことのできるファイル・
100
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ハンドルの最大数を増加するようプロンプトを出していることもわかりました。最終的に、
厄介な照会を改善するために 2 つの索引が追加されました。
db2 connect to jcrdb
db2 alter bufferpool IBMDEFAULTBP IMMEDIATE size 26000
db2 alter bufferpool ICMLSMAINBP32 IMMEDIATE size 24000
db2set DB2_ASYNC_IO_MAXFILOP=512
db2 update db cfg for jcrdb using MAXFILOP 512
101
WEBSPHERE PORTAL 7.0 TUNING GUIDE
db2 create index taw_entry_idx2 on jcr.ev_entry (parentid)
db2 reorgchk update statistics on table jcr.ev_entry
db2 create index taw_ICMSTJCRWSX_2 on jcr.icmstjcrws (basewsid, wstype)
db2 reorgchk update statistics on table jcr.icmstjcrws
db2stop force
db2start
最後に、必要なデータベース・オブジェクトに十分なメモリーを割り当てるため、DB2 を 64
ビット・モードで使用することをお勧めします。オーサリング環境では、データベースに
集中した作業負荷となる場合があるため、これが特に重要となります。テストの際、デー
タベース・メモリーはこの作業負荷の制限要因となっており、64 ビットに変更することで、
キャパシティーを大幅に向上させることができました。
Z/OS
このセクションでは、テストの際に z/OS バックエンド・データベース用に DB2 9 で行っ
たチューニングについて説明します。開始にあたり、いくつかの一般的な推奨事項を示し
ます。
•
DB2 z/OS サーバーが Portal/WCM のインストールとは異なる LPAR にある場合、ユ
ニバーサル・ドライバーのタイプ 4 データベース・ドライバーを使用する必要があり
ますが、z/OS 用の DB2 が同じ LPAR にある場合は、タイプ 2 のドライバーも使用
することができ、こちらが推奨構成となります。
DB 転送プロセスの一部として、Portal で WCM をサポートする 15 のデータベースが作成
されました。リリース、カスタマイズ、コミュニティー、Likeminds、フィードバックにそ
れぞれ 1 つずつ、JCR に 10 個です。
バッファー・プール
競合を回避するため、Portal で使用するためのバッファー・プールを別に作成するのも有
益です。Portal データベースとは別に JCR データベース用のバッファー・プール・セット
を作成することをお勧めします。次の表に、わたしたちの構成の設定を示します。
102
WEBSPHERE PORTAL 7.0 TUNING GUIDE
表 31: DB2 z/OS バッファー・プール設定
バッファー・プール設定
データベース・ド
wkplc_dbdomain.prop
メイン
erties
RELEASE
<domain>.Db4KBuffer
CUSTOMIZATION
PoolName
DB2 BP
BP2
BP ページサ
BP サ イ
イズ (KB)
ズ
4
80000
PGFIX
用途
YES
FEE、LIK、REL、COM、
CUS 表 ス ペ ー ス
COMMUNITY
4K
BPOOL
LIKEMINDS
<domain>.DbIndex4K
FEEDBACK
BufferPoolName
domain>.Db32KBu
BP3
4
80000
YES
FEE、LIK、REL、COM、
CUS 索引スペース
BP32K1
32
20000
YES
REL、CUS、COM お
よびアプリケーショ
fferPoolName
ン 32K BPOOL
JCR
jcr.Db4KBufferPo
BP4
4
150000
YES
JCR 表スペース 4K
BPOOL
olName
jcr.DbIndex4KBuff
BP5
4
150000
YES
JCR 索引スペース
BP32K1
32
20000
YES
JCR 32K BPOOL
BP1
4
40000
NO
JCR で ユ ー ザ ー 表
erPoolName
jcr.Db32KBufferP
oolName
jcr.bp4ktables
に使用される 4K バ
ッファー・プール
jcr.bp4kindexes
BP1
4
40000
NO
JCR で ユ ー ザ ー 表
の索引の作成に使用
される 4K バッファ
ー・プール
jcr.bp16ktables
BP16K1
16
20000
YES
JCR で ユ ー ザ ー 表
に 使 用 さ れ る 16K
バッファー・プール
jcr.bp32ktables
BP32K1
32
20000
YES
JCR で ユ ー ザ ー 表
に 使 用 さ れ る 32K
バッファー・プール
jcr.bp8ktables
BP8K1
8
20000
YES
JCR で ユ ー ザ ー 表
に使用される 8K バ
ッファー・プール
jcr.blobBufferpool
BP32K1
32
20000
103
WEBSPHERE PORTAL 7.0 TUNING GUIDE
YES
BLOB 表スペース
PGFIX は ALTER BUFFERPOOL パラメーターです。PGFIX が YES に設定されている場合、
DB2 は一度バッファー・ページを固定すると、実記憶でこれを固定したまま維持できます。
これにより、処理時間がかからないようにすることができます。
オーサリング用の JCR 照会最適化オプション
CPU リソースを大量に消費する特定の JCR 照会は REOPT(ONCE) で実行すると効果が
得られることがわかりました。REOPT(ONCE) により、DB2 は照会でのリテラル値に基づ
いてアクセス・パスを再計算します。わたしたちは、JCR 照会のみのために、別の DISTSERV
パッケージ・セットをバインドしました。新しいパッケージ・セットは、-reopt once およ
び -collection パラメーターで DB2 Jcc バインダー・ユーティリティーを使用してバイン
ドしました。JCR データ・ソースの CURRENT PACKAGESET カスタム・プロパティーで
はコレクションに指定された値を使用しました。
新しいパッケージ・セットをバインドするには、以下を使用します。
java com.ibm.db2.jcc.DB2Binder -url jdbc:db2://<hostname>:<drdaport>/<DB2 Location Name>
-user <username> -password <password> -collection <collection name> -reopt once
104
WEBSPHERE PORTAL 7.0 TUNING GUIDE
新しいパッケージ・セットを使用するための JCR データ・ソースの更新
管理コンソールの「リソース (Resources)」→「JDBC」で「データ・ソース (Data Sources)」
をクリックし、
適切な有効範囲を選択して「JCR データ・ソース (JCR Datasource)」をクリックします。
「カスタム・プロパティー (Custom properties)」をクリックします。
currentPackageSet プロパティーの値を上記手順で新しいパッケージ・セットをバインドす
る際に指定したコレクションの値に更新します。
WCM レンダリング用の DB2 ドライバー・パッケージの変更
レンダリングでは限定された数の異なる SQL が頻繁に実行されるため、-keepdynamic yes
および –collection パラメーターで DB2 Jcc バインダー・ユーティリティーによりバイン
ドされた新しい JCC パッケージ・セットを使用することで、DB2 の短時間での準備によ
るオーバーヘッドを削減しました。すべてのデータ・ソースの CURRENT PACKAGESET カ
スタム・プロパティーで、コレクションに指定された値を使用しました。
新しいパッケージ・セットをバインドするには、以下を使用します。
java com.ibm.db2.jcc.DB2Binder -url jdbc:db2://<hostname>:<drda port>/<DB2 Location Name>
-user <username> -password <password> -collection <collection name> -keepdynamic yes
新しいパッケージ・セットを使用するためのデータ・ソースの更新および keepDynamic パ
ラメーターの有効化
1. 管理コンソールの「リソース (Resources)」→「JDBC」で「データ・ソース (Data Sources)」
をクリックします。
2. 適切な有効範囲を選択して「データ・ソース (Datasource)」をクリックします (すべての
データ・ソースのプロパティーを更新します)。
3. 「カスタム・プロパティー (Custom properties)」をクリックします。
4. currentPackageSet プロパティーの値を、上記手順で新しいパッケージ・セットをバイン
ドする際に指定したコレクションの値に更新します。
5. keepDynamic プロパティーの値を更新し、1 に設定します。
DB2 Z/OS の追加リソース
•
. WebSphere Portal v6 の
WCM/JCR デ ー タ ベ ー ス 表 の 使 用 法 情 報
105
WEBSPHERE PORTAL 7.0 TUNING GUIDE
http://www-01.ibm.com/support/docview.wss?uid=swg21255445
•
. z/OS へ の リ モ ー ト
TCP ア ク セ ス で 可 能 な パ フ ォ ー マ ン ス の 改 善
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10621
•
. DB2 9 for z/OS のパフォーマンスに関するトピック
http://www.redbooks.ibm.com/redbooks/pdfs/sg247473.pdf
106
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Oracle のチューニング (レンダリングおよびオーサリング)
Oracle 10g では場合によって、Enterprise Manager コンソールの SQL Tuning Advisor により、
以下のような SQL 照会にパフォーマンス不良としてフラグが立てられました。パフォーマ
ンス不良の原因は、オプティマイザーが、既存の索引を使用せずに表走査を行う、不適切
な照会のアクセス・プランを選択しており、これにより照会の応答時間が長引き、データ
ベースの CPU 使用率が高まることでした。
SELECT OID, CREATED, MODIFIED, RES_TYPE, EXTERNAL_OID, EXTERNAL_UID, PARENT_OID,
OWNER_TYPE, OWNER_UID, INHERITANCE, PROPAGATION, EXTERNALIZED, IS_PRIVATE,
NAME, IS_LEAF FROM jcr.PROT_RES WHERE (PARENT_OID = :1 AND RES_TYPE = :2)
この照会で問題がある場合、次の索引を追加できます。また、以下のコマンドを実行する
ことにより、PROT_RES 表でより詳細な統計の収集を再実行することもできます。
CREATE INDEX "JCR"."IX2110I" ON "JCR"."PROT_RES" ("PARENT_OID", "RES_TYPE");
exec
dbms_stats.gather_table_stats(
ownname=>
'JCR',
tabname=>
'PROT_RES'
,
estimate_percent=> null, cascade=> TRUE, degree=> NULL, no_invalidate=> FALSE, granularity=>
'ALL', method_opt=> 'FOR ALL COLUMNS');
この索引を追加した後、この照会のアクセス・プランが表走査を新しい IX2110I または既
存の IX2110D 索引を使用した索引走査に置き換えることが確認されました。どちらの場合
でも、データベースの CPU 使用率は大幅に低減されました。
107
WEBSPHERE PORTAL 7.0 TUNING GUIDE
クラスターのチューニング
わたしたちは、3 ノードの水平クラスター環境 (データベース・セッション・パーシスタン
スあり、またはなし) や 6 メンバーの垂直クラスター環境など、いくつかの構成で基本ポ
ータル・シナリオを評価してきました。一般に、これらのクラスター評価では、基本ポー
タル・シナリオで使用されたものと同じチューニングが使用されていました。クラスター
環境に固有の追加設定を次に示します。
アプリケーション・サーバーのチューニング
Dynacache カスタム・プロパティー
クラスター・メンバー間で送信される Dynacache メッセージの数およびサイズを削減する
ため、いくつかのプロパティーを設定できます。これにより、クラスター化された Portal 環
境でスケーラビリティーが向上し、リソースの消費が削減されます。これらのプロパティ
ーを設定するには、以下の手順を実行します。
1) 管理コンソールを開き、これにログインします。
2) 「アプリケーション・サーバー (Application servers)」→「WebSphere_Portal」→「Java お
よびプロセス管理 (Java and Process Management)」→「プロセス定義 (Process Definition)」
→ 「 Java 仮 想 マ シ ン (Java Virtual Machine)」 → 「 カ スタ ム ・ プ ロパ テ ィ ー (Custom
properties)」→「新規 (New)」をクリックします。
3) 「汎用プロパティー (General Properties)」で、次の情報を追加します。
「名前 (Name) 」:
「値 (Value)」:
com.ibm.ws.cache.CacheConfig.ignoreValueInInvalidationEvent
true
パフォーマンスに大きな影響を与えることのできる、com.ibm.ws.cache.CacheConfig.
propogateInvalidationsNotShared というカスタム・プロパティーがあります。初期状態の
Portal ではこのプロパティーは未設定で、デフォルトは false です。これは最良のパフォー
マンスを提供します。true に設定すると、Dynacache は NOT_SHARED キャッシュ・イン
スタンスのキャッシュ・エントリーの挿入および更新時にクラスター内のピア・メンバー
に無効化を送信します。これにより、特に z/OS プラットフォームでは、重大なパフォー
マンスの影響が生じます。したがって、このプロパティーは削除 (またはデフォルト値の
false に設定) する必要があります。これは、WebSphere Portal では機能的な影響を与えま
せん。
108
WEBSPHERE PORTAL 7.0 TUNING GUIDE
動的キャッシュ複製
1. クラスター内のすべてのノードで、動的キャッシュ複製を有効にする必要があります。
設定方法:
1) 管理コンソールを開き、これにログインします。
2) 「アプリケーション・サーバー (Application servers)」→「WebSphere_Portal」→「コンテ
ナー・サービス (Container Services)」→「動的キャッシュ・サービス (Dynamic cache service)」
をクリックし、さらに「キャッシュ複製の有効化 (Enable cache replication)」→「複製のタ
イプ (Replication Type)」→「非共有 (Not Shared)」をクリックします。
2. 動的キャッシュのサイズをクラスター内のすべてのノードで同じに設定します。
設定方法:
1) 管理コンソールを開き、これにログインします。
2) 「アプリケーション・サーバー (Application servers)」→「WebSphere_Portal」→「コンテ
ナー・サービス (Container Services)」→「動的キャッシュ・サービス (Dynamic cache service)」
をクリックし、「キャッシュ・サイズ (cache size)」を 3000 に設定します。
3. 各 ノ ー ド を 再 同 期 さ せ ま す 。 管 理 コ ン ソ ー ル か ら 、「 シ ス テ ム 管 理 (System
administration)」→「ノード (Nodes)」にナビゲートし、クラスター内のすべてのノードを選
択して、「完全再同期 (Full Resynchronize)」をクリックします。
VMM コンテキスト・プーリング
VMM コンテキスト・プーリング用のクラスターのチューニングは、Deployment Manager で
行う必要があります。その後、管理コンソールから各ノードに対して完全再同期を行いま
す。この設定方法については、『VMM コンテキスト・プーリング』を参照してください。
メモリー間のセッション・パーシスタンスのチューニング
クラスターでメモリー間のセッション・パーシスタンスを有効にするには、複製ドメイン
を作成する必要があります。その後、WebSphere 管理コンソールの「セッション管理
(Session Management)」で各 Portal サーバーに対してメモリー間セッションの複製を構成す
ることができます。3 種類の複製モードのいずれかを選択します。わたしたちの環境では、
デフォルトの「両方 (BOTH)」(クライアントおよびサーバー) モードを使用します。これは、
セッションが Portal クラスター・メンバーから別のクラスター・メンバーに送信されるこ
109
WEBSPHERE PORTAL 7.0 TUNING GUIDE
とを意味します。別個のアプリケーション・サーバーは、セッション・データを格納する
ように定義されていません。
セッション・パーシスタンスのこのモードにより、各クラスター・メンバーは複製を使用
しない場合より多くのセッション・データを保持します。したがって、ヒープ使用率の通
常の監視と同様に、このタイプのセッションの複製には 64 ビット環境をお勧めします。
前のクラスターのチューニングのセクションで説明したチューニングに加えて、次の追加
チューニングが適用されます。
110
WEBSPHERE PORTAL 7.0 TUNING GUIDE
JVM ヒープ
メモリー要件に対応するため、JVM ヒープ・サイズ、新しい領域のサイズ、および共用ク
ラス・キャッシュ・サイズは増大しています。
パラメーター
初期/最大ヒープ・サ
新しい領域のサイズ
イズ
使用する値
共用クラス・キャッ
シュ・サイズ
4096 MB
-Xmn1024m
-Xscmx150m
セッション・パーシスタンスのチューニング
表 32: WebSphere メモリー間セッション・パーシスタンスのチューニング
パラメーター
設定
詳細
メモリー内セッ
40000
メモリー内セッション・カウントのデフォルト値は 1000
ション・カウン
です。セッション・パーシスタンスが有効な負荷には、
ト
メモリー内セッション・カウントを 40000 に設定しま
す。アクティブなセッションの期待される作業セットを
カバーするのに十分な大きさとなるように、この数値を
選択しています。PMI を使用してセッション・カウント
を監視し、それに応じて調整してください。
パラメーターの設定方法:
WebSphere 管理コンソールで、「サーバー (Servers)」→
「アプリケーション・サーバー (Application Servers)」→
「 WebSphere Portal 」 → 「 コ ン テ ナ ー 設 定 (Container
Settings)」→「セッション管理 (Session Management)」→
「メモリー内最大カウント (Max in memory)」にナビゲー
トし、「メモリー内最大カウント (Max in memory)」を設
定します。
書き込み頻度
時間基準 10
パラメーターの設定方法:
秒
WebSphere 管理コンソールで、「サーバー (Servers)」→
「アプリケーション・サーバー (Application Servers)」→
「 WebSphere Portal 」 → 「 コ ン テ ナ ー 設 定 (Container
Settings)」→「セッション管理 (Session Management)」→
「分散環境設定 (Distributed environment settings)」→「カ
スタム・チューニング・パラメーター (Custom tuning
parameters)」→「カスタム設定 (Custom settings)」→「書
111
WEBSPHERE PORTAL 7.0 TUNING GUIDE
き込み頻度 (Write frequency)」にナビゲートします。
書き込み内容
更新された
パラメーターの設定方法:
属性のみ
WebSphere 管理コンソールで、「サーバー (Servers)」→
「アプリケーション・サーバー (Application Servers)」→
「 WebSphere Portal 」 → 「 コ ン テ ナ ー 設 定 (Container
Settings)」→「セッション管理 (Session Management)」→
「分散環境設定 (Distributed Environment Settings)」→「カ
スタム・チューニング・パラメーター (Custom tuning
parameters)」→「カスタム設定 (Custom settings)」→「書
き込み内容 (Write contents)」にナビゲートします。
セッション・ク
false
パラメーターの設定方法:
リーンアップの
WebSphere 管理コンソールで、「サーバー (Servers)」→
スケジュール
「アプリケーション・サーバー (Application Servers)」→
「 WebSphere Portal 」 → 「 コ ン テ ナ ー 設 定 (Container
Settings)」→「セッション管理 (Session Management)」→
「分散環境設定 (Distributed Environment Settings)」→「カ
スタム・チューニング・パラメーター (Custom tuning
parameters)」→「カスタム設定 (Custom settings)」にナ
ビゲートし、
「セッション・クリーンアップのスケジュー
ル (Schedule sessions cleanup)」のチェック・マークを外
します。
112
WEBSPHERE PORTAL 7.0 TUNING GUIDE
WAS フィックスパック
WebSphere フィックスパック 7.0.0.13 には、クラスターに有益な多くのフィックスが含ま
れています。したがって、このレベル以降のフィックスパックを使用することをお勧めし
ます。
AIX ネットワーク
AIX カーネル・パラメーター somaxconn は、TCP 接続の最大 listen バックログを指定し
ます。このパラメーターは、わたしたちの評価では、負荷を処理するため 32767 に増やし
ています。これは 3 つの Portal ノードすべてに設定しました。
設定方法については、『AIX Network tuning』を参照してください。
プラグイン
以下のプラグイン・パラメーターを設定します。
•
. IgnoreAffinityRequests:false (デフォルト = true)
IgnoreAffinityRequests は、ラウンドロビン・アルゴリズムに基づいてサーバーを選択する際
にサーバーに対して作成されたアフィニティー要求の数をプラグインが無視するかどうか
を指定します。これを false に設定すると、特にセッション・パーシスタンスが有効な環境
では、より良いロード・バランシングが行われます。
詳細および設定方法については、下記のサイトを参照してください。
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.
multiplatform.doc/info/ae/ae/rwsv_plugincfg.html
データベースに対するセッション・パーシスタンスのチューニング
データベースに対してセッション・パーシスタンスを有効にするには、非 XA JDBC ドライ
バーを持つデータ・ソースを作成する必要があります。さらにわたしたちは、32K のペー
ジ・サイズの DB2 セッション・データベースを、ここに大量のデータを書き込めるようパ
フォーマンスを最適化するように構成しました。DB2 セッション・データベースの表スペ
113
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ースの構成とページ・サイズの詳細については、WebSphere Application Server のインフォ
メーション・センターにアクセスしてください。適用される追加のチューニングを以下に
示します。
表 33: WebSphere セッション・パーシスタンスのチューニング
パラメーター
設定
詳細
メモリー内セッ
40000
メモリー内セッション・カウントのデフォルト値は 1000
ション・カウン
です。セッション・データベース・パーシスタンスが有
ト
効な負荷には、メモリー内セッション・カウントを 40000
に設定します。アクティブなセッションの期待される作
業セットをカバーするのに十分な大きさとなるように、
この数値を選択しています。PMI を使用してセッショ
ン・カウントを監視し、それに応じて調整してください。
パラメーターの設定方法:
WebSphere 管理コンソールで、「サーバー (Servers)」→
「アプリケーション・サーバー (Application Servers)」→
「 WebSphere Portal 」 → 「 コ ン テ ナ ー 設 定 (Container
Settings)」→「セッション管理 (Session Management)」→
「メモリー内最大カウント (Max in memory)」にナビゲー
トし、「メモリー内最大カウント (Max in memory)」を設
定します。
オーバーフロー
無効
セッションのオーバーフローの許可のデフォルト値は、
の許可
チェックされた状態です。メモリー内に保持されるセッ
ションの総数を制限するため、セッション・データベー
ス・パーシスタンスではこれを無効にしました。
パラメーターの設定方法:
WebSphere 管理コンソールで、「サーバー (Servers)」→
「アプリケーション・サーバー
(Application Servers)」→
「 WebSphere Portal 」 → 「 コ ン テ ナ ー 設 定 (Container
Settings)」→「セッション管理 (Session Management)」→
「オーバーフローの許可 (Allow overflow)」にナビゲート
し、このチェック・マークを外します。
セッション分散
データベー
パラメーターの設定方法:
環境
スの表スペ
WebSphere 管理コンソールで、「サーバー (Servers)」→
114
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ース 32K ペ
「アプリケーション・サーバー
ージで有効
「 WebSphere Portal 」 → 「 コ ン テ ナ ー 設 定 (Container
Settings)」→「セッション管理
(Application Servers)」→
(Session Management)」
→「分散環境設定 (Distributed Environment Settings)」に
ナビゲートし、データベースを次のように設定します。
「Jndi 名 (Jndi name)」:jdbc/sessions (セッションのデー
タ・ソースに従って設定)
「ユーザー ID/パスワード(Userid/password)」:セッショ
ン・データベースに従って設定
「DB2 行サイズ (DB2 Row size)」:ROW_SIZE_32KB
Tablespace name=sess_user32k (データベースの表スペー
スに従って設定)
「複数行スキーマ (Multiple row schema)」:チェックを外す
セッション・デ
最小 = 10
パラメーターの設定方法については、『DB2 データベー
ータ・ソースの
最大 = 35
ス・サーバーのチューニング』を参照してください。
15
パラメーターの設定方法については、『DB2 データベー
ConnectionPool
サイズ
セッション・デ
ータ・ソース用
ス・サーバーのチューニング』を参照してください。
に用意されるス
テートメント・
キャッシュ・サ
イズ
セッション・データベースのチューニング
セッションのパーシスト用に、IBM DB2 データベース・サーバーを使用します。わたした
ちの専用セッション・データベース・サーバーに適用したチューニングは以下のとおりで
す。
db2set DB2_USE_ALTERNATE_PAGE_CLEANING=ON
db2set DB2_RR_TO_RS=YES
db2set DB2_PARALLEL_IO=*
115
WEBSPHERE PORTAL 7.0 TUNING GUIDE
# disable session tablespace file system caching
db2 alter tablespace sess_user32k NO FILE SYSTEM CACHING
db2 alter tablespace sess_temp32k NO FILE SYSTEM CACHING
db2 “update db cfg for <sess70> using locklist 5120”
db2 “update db cfg for <sess70> using maxlocks 80”
db2 “update db cfg for <sess70> using dbheap 4800”
db2 “update db cfg for <sess70> using num_iocleaners 20”
db2 “update db cfg for <sess70> using num_ioservers 20”
db2 “update db cfg for <sess70> using logbufsz 256”
db2 “update db cfg for <sess70> using logfilsiz 12288”
db2 “update db cfg for <sess70> using logprimary 40”
垂直クラスターのチューニング
わたしたちの垂直クラスター環境では以下のように設定しました。
•
. JVM 間で送信される Dynacache メッセージの数およびサイズを削減するには、『ク
ラスターのチューニング』のセクションの『Dynacache カスタム・プロパティー』を
参照してください。垂直クラスター用の追加 DynaCache プロパティーを次に示します。
Dynacache
値
com.ibm.ws.cache.CacheConfig.cacheEntryWin
10
dow
com.ibm.ws.cache.CacheConfig.cacheInvalidate
10
EntryWindow
com.ibm.ws.cache.CacheConfig.propogateInvali
FALSE
dationNotShared
•
. 動的キャッシュのサイズを 3500 に増やします。
設定方法:「Portal サーバー (Portal Server)」→「コンテナー・サービス (Container Services)」
→「動的キャッシュ・サービス (Dynamic Cache Service)」にナビゲートし、Cache size = 3500
に設定します。
•
. LDAP サーバーへの同時アクセスのパフォーマンスを向上させる方法については、
『VMM コンテキスト・プーリング』を参照してください。
•
. 次のコマンドを使用して、リリース・データベースの DBHEAP を増やします。
db2 “update db cfg for <release> using dbheap 4800”
116
WEBSPHERE PORTAL 7.0 TUNING GUIDE
その他のパフォーマンス・チューニング・オプション
上記のシナリオに加えて、WebSphere Portal では、特定のシナリオで役に立つその他のチ
ューニング・オプションをいくつか用意しています。このようなオプションには以下のも
のがあります。
•
. ネスト・グループ・キャッシュの使用
•
. ユーザーの最終ログイン時刻の記録
•
. アクセス制御におけるアクセス権の取得の最適化
•
. ポータルの起動パフォーマンスの改善
•
. ユーザー属性の取得の管理
•
. 動的コンテンツ機能の使用
•
. パーソナライゼーションのベスト・プラクティス
•
. 実社会でのネットワークの考慮
ネスト・グループ・キャッシュ
このガイドの以前のバージョンでは、ネスト・グループ・キャッシュ
(com.ibm.wps.ac.groupmanagement.NestedGroupCache) は無効にすることをお勧めしていま
した。環境に適した設定を行うことができるように、このキャッシュの使用方法を理解す
ることが重要です。
わたしたちのパフォーマンス測定用の実験環境を含む一部の環境では、ネスト・グループ
はアクセス許可には使用されません。このような場合、パフォーマンスの向上には、ネス
ト・グループのサポートの無効化およびネスト・グループ・キャッシュの無効化の 2 つの
設定を使用できます。これは、次の 2 つの設定で実行されます。
117
WEBSPHERE PORTAL 7.0 TUNING GUIDE
CacheManagerService 設定:
cacheinstance.com.ibm.wps.ac.groupmanagement.NestedGroupCache.
enabled=false
AccessControlDataManagementService 設定:
accessControlDataManagement.enableNestedGroups=false
ただし、アクセス権がネスト・グループに割り当てられている場合は、ネスト・グループ・
サポートの無効化は適切ではなく、上記の設定は使用されません。具体的には、ネスト・
グループ・サポートが有効になっているときにネスト・グループ・キャッシュを無効にす
ると、特に IBM Tivoli Access Manager (TAM) WebSEAL などサード・パーティーの認証ソフ
トウェアを使用する環境では、重大なパフォーマンスの問題が生じる可能性があります。
ユーザーの最終ログイン時刻の記録
デフォルトで、WebSphere Portal はユーザーのログイン時刻を記録します。これは、最近
ログインしたユーザーの数の報告に使用され、セッション再開のサポートにも必要となり
ます。これらの機能を必要としない場合は、ユーザーの最終ログイン時刻の記録を無効に
することができます。これにより、各ユーザーのログイン時の USER_DESC 表での操作の
挿入または更新が排除されます。
ユーザー・セッションのパーシスタンスの詳細については、WebSphere Portal のインフォ
メーション・センターで『ユーザー・セッションのパーシスタンスの構成』のトピックを
参照してください。ユーザーの最終ログイン時刻の記録を無効にするには、次の値が前提
条件となります。
timeout.resume.session=true
persistent.session.level=0
インフォーメーション・センターで記述されている機能的な影響をまず理解することなく、
これらの変更を行わないでください。
最終ログイン時刻の記録を無効にするには、Portal ConfigService で record.lastlogin の設定
を false に変更します。
118
WEBSPHERE PORTAL 7.0 TUNING GUIDE
アクセス制御におけるアクセス権の取得の最適化
WebSphere Portal では、プリンシパルを特定のロールに割り当てることによってアクセス
権が付与されます。プリンシパルには次の 4 つのタイプがあります。
•
. ユーザー
•
. グループ
•
. 仮想ユーザー (匿名の「ユーザー」)
119
WEBSPHERE PORTAL 7.0 TUNING GUIDE
•
. 仮想グループ (すべての認証済みユーザー)
ユーザーのアクセス権を決定する際、WebSphere Portal は、アクセス制御データベースで
これらすべてのプリンシパル・タイプについてアクセス権の割り当てをチェックします。
ただし、Portal サイトによって、これらのプリンシパル・クラスのうち 1 つ以上にロール
が割り当てられていない場合があります。例えば、アクセス制御にグループが使用されな
い場合、おそらくロールはグループに割り当てられません。
この場合、パフォーマンスの最適化が可能です。特定のプリンシパル・タイプにはロール
が割り当てられないことを WebSphere Portal に伝えることにより、これらの照会は実行さ
れなくなります。これにより、ポータル・サーバーおよびデータベース・サーバーでの処
理時間を節約できます。
ロールは常に特定のドメイン内のリソースに存在するので、このパフォーマンスの最適化
はリソース・ドメインのレベルで指定されます。したがって、その構成によって、WebSphere
Portal は「このドメインのこのプリンシパル・タイプにはロール割り当てが存在しない」(例:
「コミュニティー・ドメイン内のグループにはロール割り当てが存在しない」) ということ
を認識します。
このパフォーマンスの最適化を有効にするには、まずロール割り当てを持たないプリンシ
パル・タイプとそのドメインを決定します。次に、ロールの割り当てを持たない各プリン
シパル・タイプとドメインのペアに対し、以下にエントリーを追加します。
AccessControlDataManagementService.properties. The format is:
accessControlDataManagement.domain.domain-name.disableRolesFor.
principal-type=true
domain-name は目的のリソース・ドメインに、principal-type は目的のプリンシパル・タイ
プに置き換えます。例えば、コミュニティー・ドメイン内のグループにはロール割り当て
が存在しないことを示すには、次のような設定になります。
accessControlDataManagement.domain.community.disableRolesFor.groups=false
プリンシパル・タイプは次のように指定されます。
•
. ユーザー: users
120
WEBSPHERE PORTAL 7.0 TUNING GUIDE
•
. グループ: groups
•
. 仮想ユーザー: v_users
•
. 仮想グループ: v_groups
要件が変更され、無効であったロール割り当てが再度必要になった場合は、値を「false」に
することでこの設定を元に戻すことができます。例えば、コミュニティー・ドメイン内の
グループでロール割り当てを使用するには、設定を次のように変更します。
accessControlDataManagement.domain.community.disableRolesFor.groups=true
121
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ポータルの起動パフォーマンスの改善
WebSphere Portal 7.0 には、アプリケーション・サーバーの起動に必要な時間を削減するた
めのオプションが 2 つあります。これらは次のとおりです。
•
. 開発モード:ソフトウェア開発およびテスト環境用のモードです。負荷の高い環境や実
稼働環境での使用は想定していません。このような環境では実行時パフォーマンスに
悪影響を与える可能性があります。
•
. Portal ライト・モード:実稼働環境やテスト環境で使用できるモードです。起動パフォ
ーマンスが向上します。さらに、ほとんどのデプロイメントで、メモリー消費の削減
が見られます。
WebSphere Portal 開発モード
WebSphere Portal 7.0 では、より迅速に起動できるように、大幅に起動パフォーマンスを向
上させる「開発モード」を導入しました。これは、WebSphere Portal を頻繁に停止および
起動する必要のある開発環境で非常に便利です。
ただし、このモードは実稼働環境やパフォーマンス・ベンチマーク環境ではなく、開発環
境またはテスト環境でのみ使用するよう意図されていることに注意することが重要です。
開発モードは WebSphere Portal 内のほとんどすべてのアプリケーションの遅延起動を有効
にします。これにより、負荷のある状態でアプリケーションに最初にアクセスしたとき、
パフォーマンスに影響が生じる可能性があります。また、開発モードでは、負荷時にキャ
パシティーを削減するという代償を払って起動速度を上げるように、JVM の起動方法を変
更します。
開発モードに切り替えるには、enable-develop-mode-startup-performance 構成タスク実行し、
構 成 を 完 了 し て ポ ー タ ル の 起 動 を 最 適 化 し ま す 。 こ の 変 更 は 、
disable-develop-mode-startup-performance 構成タスクを使用して元の値に戻すことができ
ます。
詳細については、次の URL にアクセスしてください。
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1m0/index.jsp?topic=/com.ibm.wp.ent.doc/in
stall/inst_opt.html
122
WEBSPHERE PORTAL 7.0 TUNING GUIDE
WebSphere Portal ライト・モード
WebSphere Portal 7.0 以降では、実稼働環境でポータルの起動時間を改善し、メモリー消費
を削減できる、新しいポータル・ライト・モードを用意しています。
詳 細 に つ い て は 、 次 の
URL
に ア ク セ ス し て く だ さ い 。
http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Enabling_and_disabling_portal_light_mode_wp7
123
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ユーザー属性の取得の管理
ユーザー・ディレクトリーには、ユーザー ID とパスワードだけではなく、ユーザーに関す
るその他多くの情報 (属性) も含まれています。ディレクトリー・サーバーには、ユーザー
ごとに多くの属性を含めることができるため、ユーザーの参照がそれぞれこれらすべての
属性の取得を必要とする場合、Portal サーバー・ノードとディレクトリー・サーバー・ノ
ードの両方にパフォーマンスのペナルティーが課せられます。
したがって WebSphere Portal では、これらの属性のロードの最適化を試みます。基本属性
セットと最小属性セットの 2 つのユーザー属性セットが定義されます。ユーザーがディレ
クトリーから取得される要因となるアクションによって、基本属性セットまたは最小属性
セットが取得されます。通常、基本属性セットはユーザーが取得されるときにロードされ
ます (ユーザーのログイン時など)。ユーザーの検索時にユーザーがルックアップされる場
合は、最小属性セットがロードされます。例えば、これはページへのアクセス権を割り当
てるユーザーを検索する場合に発生することがあります。
デフォルトで、WebSphere Portal は次のようにユーザー属性セットを定義します。
•
. 基本セット:基本セットには次の属性が含まれます。
o uid
o cn
o sn
o preferredLanguage
o ibm-primaryEmail
o givenName
o displayName
•
. 最小セット:
o uid
o cn
追加属性が必要な場合はどうなるでしょうか。例えば、countryName というユーザー属性
を必要とするポートレットについて考えてみます。当該ユーザーがログイン時にルックア
ップされ、基本属性セットが取得されたものとします。属性 countryName は基本セットに
ないため、そのユーザーの全レコード (そのすべての属性を含む) がその時点でディレクト
リー・サーバーから取得されます。これには、ディレクトリー・サーバーへの 2 つ目の要
124
WEBSPHERE PORTAL 7.0 TUNING GUIDE
求が必要です。また、すべてのユーザー属性が 2 つ目の要求で取得されるため、WebSphere
Portal サーバーでより多くのメモリーが消費されることになりかねません。
このことは、ディレクトリー・サーバーでの応答時間の改善と負荷の削減の両方を実現す
るための、パフォーマンス・チューニングの重要なポイントを示しています。ユーザー属
性が一般的に必要とされる場合、これは基本属性セットに含め、最初のルックアップで取
得されるようにし、2 つ目の要求の必要性を排除します。一方、属性が頻繁には必要とさ
れない場合は、これを基本属性セットから外し、すべてのユーザーに対してこれが取得さ
れないようにします。
125
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ユーザー属性のフルフェッチの特定
ディレクトリー・サーバーへの 2 つ目の要求を行い、ユーザー属性のフルセットを取得す
る状況を、どのようにして特定できるでしょうか。これは、ポータル・サーバーでのトレ
ースのチューニングを必要とし、かなりのパフォーマンス・オーバーヘッドが課せられる
場合があるため、実稼働環境ではなく、テスト環境またはステージング環境で行うのが最
適です。この状態を探すことができるトレースは 2 つあります。1 つ目のトレースでは、
必要なすべてのユーザー属性が取得されたかどうかを示します。これが偽の場合、ユーザ
ー情報のフルフェッチが行われます。2 つ目のトレースでは、要求されている属性を示し
ます。これにより、基本セットに追加する必要のある属性がわかります。
2 つのトレース・ストリングは次のとおりです。
com.ibm.wps.um.PrincipalImpl=all=enabled
com.ibm.wps.um.PumaProfileImpl=all=enabled
これらのトレースを有効にし、テストするユースケースを実行します。その後、trace.log で
次のメッセージを探します。
PrincipalImpl 3 com.ibm.wps.um.PrincipalImpl isCompletelyLoaded false
このメッセージは同一ユーザーで複数回出力されるため、このすべてのメッセージを確認
してください。isCompletelyLoaded の後の値が常に true の場合は、必要な属性はすべて既
にロードされており、変更の必要はありません。この例では、isCompletelyLoaded の後の値
は false で、必要なユーザー属性がすべてロードされていないことを示しています。このよ
うな場合、ユーザー・ディレクトリーからすべてのユーザー情報を再ロードすることにな
ります。
その場合、一般的にトレースでは、その後にそのユーザーの情報を再ロードするコールが
示されます。これで、ユーザー・ディレクトリーから情報がロードされるユーザーのフル
識別名がわかります。
PrincipalImpl > com.ibm.wps.um.PrincipalImpl reload ENTRY id: cn=Yin
Yin_000_992, cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software
Group,dc=ibm,dc=com
126
WEBSPHERE PORTAL 7.0 TUNING GUIDE
次に、トレース内のその上の部分で getAttributes コールを検索します。ここに、ユーザー
が要求した属性が示されます。 これは次のようになります。
PumaProfileIm > com.ibm.wps.um.PumaProfileImpl getAttributes ENTRY id:
cn=Yin Yin_000_992, cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software
Group,dc=ibm,dc=com
…more user details follow…
isExternal: false
[preferredLanguage, ibm-primaryEmail, countryName, displayName,
givenName, cn, sn, uid]
ログ・エントリーの最後の行には、要求された属性が示されます。この場合、要求された
属性は、[preferredLanguage, ibm-primaryEmail, countryName, displayName, givenName, cn, sn,
uid] です。これを基本ユーザー属性のリストと比較すると、countryName が基本ユーザー
属性に含まれていないことがわかります。実行されたアクションが一般的なものかどうか
により、これを属性の基本設定に追加することを検討します。
最小属性セット
一般に、最小属性セットは WebSphere Portal で提供されるユーザー管理アプリケーション
で十分とされるものであるため、WebSphere Portal で提供されるデフォルトから変更する
必要はありません。ただし、サイトにユーザーおよびグループを管理するためのカスタム・
アプリケーションが含まれ、このアプリケーションが最小セットの属性以外の属性を使用
する場合は、最小属性セットの拡張を検討する必要があります。
動的コンテンツ機能の使用
WebSphere Portal には、動的ユーザー・インターフェースと属性ベース管理の 2 つの動的
コンテンツ機能をサポートする、動的コンテンツ・サポート・インフラストラクチャーが
含まれています。これらの機能をどちらも使用していない場合は、動的コンテンツ・サポ
ートを無効にすることができます。属性ベース管理は、WebSphere Portal のパーソナライ
ゼーション機能で唯一の動的コンテンツ機能を使用する用途です。ポートレット内でのコ
127
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ンテンツ・スポットの配置など、パーソナライゼーションのその他の用途では、動的コン
テンツ機能は必要ありません。
動的コンテンツ機能を無効にすると、適度なパフォーマンスの効果がもたらされます。こ
の無効化により、各ユーザーに必要なメモリーが削減され、WebSphere Portal でのページ
生成の処理時間も削減されます。例えば、基本ポータル・シナリオでのある測定で、動的
コンテンツ・サポートを無効にすると、キャパシティーが約 5% 向上しました。
動的コンテンツ・サポートは、ConfigService.properties リソース・プロバイダーにカスタム・
プロパティーを追加することにより無効になります。このプロパティーは次のとおりです。
content.topology.dynamic=false
構成プロパティーの更新方法の詳細については、WebSphere Portal のインフォメーション・
センターの『構成サービスの概要』を参照してください。
パーソナライゼーションのベスト・プラクティス
WebSphere Portal のパーソナライゼーションでは、ユーザーのコンテンツを、そのユーザ
ーのプロファイルの情報とビジネス・ルールに基づいて選択できます。パーソナライゼー
ションの詳細については、Portal のインフォメーション・センターの『コンテンツの個別
設定』を参照してください。
サイトでパーソナライゼーションを使用している場合は、可能な限りのパフォーマンスを
得ていたいはずです。パーソナライゼーションのパフォーマンスに関するトピックは、
http://www-10.lotus.com/ldd/portalwiki.nsf/dx/personalization-best-practices
Practices for using Personalization in WebSphere Portal』を参照してください。
128
WEBSPHERE PORTAL 7.0 TUNING GUIDE
の
『
Best
実社会でのネットワークの考慮
わたしたちの実験環境は、クライアントとサーバーが同じ LAN セグメント上に存在すると
いう快適な状況にあり、帯域幅が広く、遅延の少ないネットワーク接続を利用できました。
しかし、これは実際のクライアントで一般的なケースではありません。広域ネットワーク
では、遅延が著しい場合もあり、帯域幅は制限されています。この場合、ページ・コンテ
ンツをサーバーからクライアントへ転送する時間が、全ページ応答時間の重要な一因とな
ります。
この状況の緩和に役立ついくつかの手順を以下に示します。
•
. HTTP サーバーでコンテンツを圧縮する。
•
. クライアント・サイドのイメージ、Javascript ファイル、およびスタイル・シートの
キャッシュを許可する。
•
. ログイン・ページをキャッシュ可能に設定する。
これらの手順の詳細を以下に示します。
HTTP サーバーでのコンテンツの圧縮
WebSphere Portal サイトで提供されるコンテンツの多くは、伝送時間を削減し、ネットワ
ーク帯域幅を節約するため、圧縮することができます。通常、イメージは圧縮しません (こ
れらは通常圧縮形式で格納されているため) が、その他のタイプのコンテンツは圧縮により
大幅なサイズの削減が見られます。
IBM HTTP Server は、mod_deflate モジュールにより Deflate 圧縮をサポートします。これ
を有効にすると、HTTP サーバーはブラウザーが送信する Accept-Encoding: ヘッダーをチ
ェックし、圧縮されたバージョンのコンテンツを受け入れられるかどうかを確認します。
受け入れ可能な場合、HTTP サーバーはブラウザーに送信する前にこのコンテンツを圧縮し
ます。
わたしたちは、mod_deflate を mod_cache と共に使用していくつかの問題に気付きました。
したがって、この両方を同じ HTTP サーバー・デプロイメントで使用することはお勧めし
ません。
ある測定では、Deflate 圧縮を有効にすると、平均で 65% のネットワーク・トラフィックの
129
WEBSPHERE PORTAL 7.0 TUNING GUIDE
削減が見られました。ただし、HTTP サーバーで約 10% のプロセッサー使用率の増加も見
られたため、代償がないわけではありません。
130
WEBSPHERE PORTAL 7.0 TUNING GUIDE
IBM HTTP Server で gzip 圧縮を有効にするには、httpd.conf に次の行を追加します。
# compress everything but images
LoadModule deflate_module modules/mod_deflate.so
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png|exe)$ no-gzip dont-vary
クライアント・サイド・キャッシュの有効化
HTTP プロトコルにより、サーバーはクライアントに応答をキャッシュできる時間を伝える
ことができます。クライアントがキャッシュにコンテンツを保持している場合、クライア
ントはこのコンテンツを再度要求する必要はなく、コンテンツを取得するためのサーバー
までの往復時間を節約できます。
このためには、キャッシュ可能にするコンテンツに Cache-Control: ヘッダーを追加します。
デフォルトで、WebSphere Portal は使用するスタイル・シートにこれらのヘッダーを含み、
そのコンテンツがクライアントで 5 日間 (432,000 秒) キャッシュ可能となります。IBM
HTTP Server で mod_headers を使用して、httpd.conf に次の行を追加することにより、イ
メージ、JavaScript、およびその他のコンテンツに同じヘッダーを追加することができます。
LoadModule headers_module modules/mod_headers.so
<LocationMatch "\.(gif|jpeg|jpg|png|ico|jsp|css|js|swf|json)$">
131
WEBSPHERE PORTAL 7.0 TUNING GUIDE
header set Cache-Control "public,max-age=86400"
</LocationMatch>
ポートレット・キャッシュ
ポートレット・キャッシュは、サーバー・サイドのレンダリング・モードでは特にページ・
ビルダー・テーマに関係しませんが、クライアント・サイドのレンダリングおよびこのテ
ーマに役立つ場合があります。
portlet.xml はポートレットの war ファイルの一部で、ポートレットの WEB-INF ディレク
トリーにあります。ポートレット・フラグメントを公的にキャッシュ可能にするには、次
のように設定します。
1. <expiration-cache>28800</expiration-cache>
2. <cache-scope>public</cache-scope>
132
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ログイン・ページをキャッシュ可能にする設定
認証されていないユーザーがログインに使用するページを、共用かつキャッシュ可能に設
定することができます。頻繁に使用されるサイトで、デフォルトのホームページを 5 分間
だけでもキャッシュ可能に設定することで、サイトの応答性を高めることができる場合が
あります。
1. 管理者としてポータルにログインし、管理ページにナビゲートします。
2. 「Portal ユーザー・インターフェース (Portal User Interface)」→「ページの管理 (Manage
Pages)」を選択します。
3. 「タイトルが次で始まる (Title starts with)」を「Login」として検索します。
4. 「ログイン・ページのページ・プロパティー (Page Properties of the Login Page)」を編集
します。
5. 「ページ・キャッシュ・オプション (Page Cache Options)」を展開します。
6. 「キャッシュの有効範囲 (Cache Scope)」を「ユーザー間の共用キャッシュ (Shared cache
across users)」ラジオ・ボタンに設定します。
7. 「キャッシュの有効期限 (Cache Expiration)」で「キャッシュの有効期限が切れるまでの
秒数(Cache expires after this many seconds)」ラジオ・ボタンをクリックします。値を 6000 な
どに設定します。
8. 「OK」をクリックして保存します。
9. これでメインの「管理」ページに戻ります。
10. 「ポートレット管理 (Portlet Management)」→「ポートレット (Portlets)」を選択します。
11. ログイン・ポートレットが表示されていない場合、
「タイトルが次で始まる (Title starts
with)」を「Login」として検索します。
12. ログイン・ポートレットで「ポートレットの構成 (Configure Portlet)」(レンチ・アイコ
ン) をクリックします。
13. HTTP およびフラグメント・キャッシュの「キャッシュの有効範囲 (Cache Scope)」で、
「すべてのユーザー間の共用キャッシュ (Share cache across all users)」を選択します。
14. HTTP およびフラグメント・キャッシュの「キャッシュの有効期限 (Cache Expiration)」
で、「ポートレット・キャッシュの有効期限が切れるまでの秒数 (Portlet cache expires after
this many seconds)」を選択します。値を 6000 などに設定します。
15. 「OK」をクリックします。
133
WEBSPHERE PORTAL 7.0 TUNING GUIDE
WebSphere Portal キャッシュ
前の章では、ここで取り上げている環境で WebSphere Portal に使用できるように変更した
具体的な値について説明しました。この章では、WebSphere Portal キャッシュ、WebSphere
Portal キャッシュで使用する一般的なパラメーター、WebSphere Portal V7.0 が提供するキ
ャッシュ・インスタンスについて説明するほか、ポータル・キャッシュのプロパティーに
関する推奨事項も交えたポータルの使用パターン例も紹介します。
一般情報
WebSphere Portal V7.0 では、キャッシュ構成プロパティーなどのポータル構成プロパティ
ーは、WebSphere Application Server 管理コンソールで管理します。これまでのリリースの
WebSphere Portal では、これらの構成プロパティーはプロパティー・ファイルに保持され
ていました。ポータル構成プロパティーの変更方法の詳細については、WebSphere Portal
Version 7.0 の情報センターで、構成プロパティーの設定に関するセクションを参照してく
ださい。
キャッシュ構成プロパティー
キャッシュ構成プロパティーは、グローバルな構成プロパティーとキャッシュ・インスタ
ンス固有のプロパティーの 2 つのグループに分類できます。グローバル・プロパティーは、
cacheglobal をプレフィックスとして持ち、キャッシュ・インスタンス固有のプロパティー
を明示的に優先して適用しない限り、すべてのキャッシュに適用されます。キャッシュ・
インスタンス固有のプロパティーは、cacheinstance をプレフィックスとして持ち、それに
キャッシュ・インスタンスの名前とプロパティーの名前が続きます。例えば、次のように
なります。
cacheinstance.com.ibm.wps.ac.ExplicitEntitlementsCache.USER_GROUP. size
キャッシュへのすべての入力は、特定のプロパティーの 1 つの組み合わせで管理されてい
ます。
変更しても問題のないキャッシュ構成プロパティーは、enabled、lifetime、size、shared、
replacement、および admit-threshold です。キャッシュ実装によっては、replacement プロ
パティーと admit-threshold プロパティーが適用されないものがあります。一般的に、共有
されていないキャッシュでのみ、これらのプロパティーを使用します。IBM WebSphere Portal
134
WEBSPHERE PORTAL 7.0 TUNING GUIDE
のサポートから具体的な指示がない限り変更してはならないプロパティーもあります。
enabled: enabled プロパティーは、キャッシュを使用するかどうかを指定します。キャッシ
ュが無効な場合、このプロパティーの値は false で、キャッシュには何の値も保持されず、
キャッシュの検索では NULL 値が返ります。このプロパティーはテストの目的でのみ変更
するものであり、実稼働環境では変更しないようにします。指定できる値は true と false
で、グローバルなデフォルト値は true です。
lifetime: lifetime プロパティーは、キャッシュでのエントリーの存続時間を秒数で指定しま
す。キャッシュにエントリーが存在している時間が lifetime プロパティーで指定した時間
を過ぎると、キャッシュからはエントリーが返されなくなります。キャッシュのエントリ
ーは、エントリーの明示的な無効化や最長未使用時間 (LRU) に基づくキャッシュからの削
除によって、存続時間に到達する前に無効にすることもできます。
値に -1 を指定すると、存続時間に制限がなくなります。この値を指定した場合は、プロ
グラム処理を使用しないとキャッシュのエントリーを無効化できなくなるので、注意が必
要です。特にアクセス制御キャッシュでは、次の理由から、無制限の存続時間はお勧めで
きません。
•
. クラスターでは、アプリケーション・サーバーの dynacache コードでの競合状態に
起因して、各ノードで処理されないキャッシュ無効化メッセージがまれに発生するこ
とがあります。このような現象が発生する確率は低いものの、現在のコード・ベース
で完全に回避することはできません。有限な存続時間を指定することで、これらのエ
ントリーを無効化できます。
•
. 有限な存続時間を指定することで、外部セキュリティー・マネージャーに外部化した
ロールに対する変更をロール・キャッシュに反映できます。
XML Access を使用して、実稼働環境の更新範囲を、定義が適切なステージング・プロセス
に制限していれば、無制限の存続時間を指定しても普通は安全です。
size: キャッシュに収容するエントリーの最大数は size プロパティーで制限します。エント
リーの数がこの制限に達すると、一定のアルゴリズムに従ってキャッシュからエントリー
が削除されます。このアルゴリズムでは、無効化したエントリーと存続期間が経過したエ
ントリーの削除、有効なエントリーに対する LRU アルゴリズムの適用などを実行すること
が普通です。
135
WEBSPHERE PORTAL 7.0 TUNING GUIDE
任意の正の整数を指定できます。キャッシュのサイズは、ポータルのメモリー要件、具体
的には Java ヒープに必要なメモリーの量に直接影響します。キャッシュのサイズを変更し
た場合は、Java ヒープのメトリックおよびパフォーマンスに対するあらゆる影響を監視し、
記録する必要があります。
shared: クラスター対応のキャッシュは、クラスターの各ノードで共有されます。これらの
キャッシュでは、WebSphere Application Server の DistributeMap インターフェースを使用し
てキャッシュ・エントリーの無効化を伝搬します。
136
WEBSPHERE PORTAL 7.0 TUNING GUIDE
指定できる値は true と false です。ほとんどの構成では、WebSphere Portal V7.0 の出荷時
のデフォルト値を適用するようにします。クラスターを使用していない環境では、このプ
ロパティーを false に設定することで別のキャッシュ実装が使用されるので、若干のパフォ
ーマンス向上が得られることがあります。ここでの単一ノード測定環境では、デフォルト
値をそのまま使用しています。
クラスターでこのパラメーターを false に設定すると、長期的にクラスター・メンバー間で
データの不整合が発生する可能性があります。
replacement: ここで取り上げているキャッシュで使用するキャッシュ置換アルゴリズムは、
キャッシュのエントリーに対する最近のアクセス頻度を対象としています。使用頻度が高
いエントリーは、使用頻度が低いエントリーに比べて、破棄される可能性が低くなります。
このパラメーターは、アクセス履歴を保持する期間を制御します。aggressive に設定すると、
最近アクセスされたエントリーのみが考慮され、古いエントリーは早い時期に破棄される
ようになります。逆の設定である conservative では、より長期間のアクセス履歴が考慮さ
れます。大半のキャッシュに適切な設定は、これらの中間的な設定である moderate です。
admit-threshold: エントリーの追加頻度がきわめて高いキャッシュでは、有用なエントリー
が早い時期に破棄される可能性があります。受け入れしきい値（admit-threshold）は、同じ
エントリーをキャッシュに挿入しようとする試みが複数回発生した後でのみ、キャッシュ
へのそのエントリーの入力を許可することにより、キャッシュにエントリーを受け入れる
頻度を制限します。デフォルト値の 0 では受け入れしきい値が設定されず、エントリーを
挿入しようとする最初の試みで、そのエントリーがキャッシュに受け入れられます。大半
のキャッシュではこの設定が適切です。0 以外の値を設定すると、同じキーを追加しようと
する試みがその値の回数発生するまで、キャッシュへのエントリー挿入は許可されません。
例えば 2 を指定すると、キャッシュにエントリーを挿入しようとする最初の 2 回の試み
は無視され、3 回目の試みで値がキャッシュに挿入されます。ここの測定環境では、どの
キャッシュに対しても admit-threshold は変更していません。
キャッシュの使用パターン
大半の WebSphere Portal キャッシュは、既にエントリーが存在する場合はそれを使用し、
存在しない場合はエントリーを追加するという単純なパラダイムに従っています。一方で、
これとは動作が異なるキャッシュも存在します。それぞれのキャッシュは、次の 4 種類の
パターンのいずれかに従います。
137
WEBSPHERE PORTAL 7.0 TUNING GUIDE
•
. パターン: 通常
既に説明した通常パターンは、次のように最も一般的なキャッシュ・パターンです。
value = cache.get(key);
if (value == null) {
value = calculateNewValue();
cache.put(key, value);
}
138
WEBSPHERE PORTAL 7.0 TUNING GUIDE
•
. パターン: 無効化確認
クラスター化環境でのキャッシュ・エントリーの無効化は、比較的高いコストが発生する
処理です。したがって多くの場合、ポータル・キャッシュでは、無効化するエントリーが
ローカル・キャッシュに実在するかどうかを確認しています。
test = cache.get(key);
if (test != null) {
cache.invalidate(key);
}
このパターンに従うキャッシュは、無効化アクションを除くすべてのアクションでは通常
パターンに従います。
•
パターン: 複数オブジェクト・タイプ
ほとんどのキャッシュでは単独のオブジェクト・タイプのみを保持しています。複数のタ
イプを保持できるキャッシュでは、これらのタイプごとに通常パターンに従います。
•
パターン: オブジェクト・タイプのカスケード
このパターンは、所定の順序で照会の対象となる複数のオブジェクト・タイプを 1 つのキ
ャッシュに保存するもので、「複数オブジェクト・タイプ」パターンの特殊な形態です。日
常的には、キャッシュ・ミスを伴うキャッシュ・ヒットが 1 回得られる可能性があります。
value = cache.get(keyA);
if (value == null) {
value = cache.get(keyB);
if (value == null) {
value = calculateNewValue();
cache.put(keyA || keyB, value); // either key could be used
}
}
139
WEBSPHERE PORTAL 7.0 TUNING GUIDE
キャッシュ・インスタンス
このセクションでは、WebSphere Portal V7.0 で使用するキャッシュとそれらのキャッシュ
を適切に構成するためのヒントについて説明します。ここで取り上げている測定環境で実
施した変更からわかるように、ポータル・キャッシュを調整する際に変更するプロパティ
ーは、多くの場合、size と lifetime です。日常的に扱う値の数が多く、Java ヒープに十分
な領域を使用できる場合は、キャッシュのサイズを大きくします。キャッシュに入れたデ
ータの変更がほとんど発生せず、各種変更を直ちにポータルに反映することにビジネス上
の重要性がそれほどない場合は、キャッシュにあるエントリーの存続時間を長くすること
が で き ま す 。 こ の セ ク シ ョ ン で 監 視 す る 変 更 は 、 フ ァ イ ル
{wp_profile}/PortalServer/config/CacheManagersService.properties で設定されているもので、
この文書で別途説明している configengine update-properties を実行することで有効になり
ます。
各キャッシュの説明では、次の属性を取り上げています。
•
. デフォルトの size、デフォルトの lifetime、およびキャッシュの使用パターン
•
. キャッシュの内容および拡大要因（キャッシュ・サイズが大きくなる原因）
•
. キャッシュに対する読み取り権限と書き込み権限に関する情報
•
. キャッシュ・エントリーの再作成に要する概略コストおよびキャッシュに入れたオブ
ジェクトの相対的サイズ。小型のオブジェクトはサイズが 16 ～ 300 バイトの範囲に
あり、キャッシュ・エントリーのサイズは最大でも数千バイトを超えません。これに
対する例外としてわかっているものに、ユーザーあたりで多数のリソースを扱うシス
テムのアクセス制御キャッシュがあります。このようなキャッシュでは、ユーザーが
アクセス可能なすべてのリソースを反映するために、50,000 バイトを超える巨大なエ
ントリーを保持できるようになっています。
•
. 推奨のプロパティー値を交えてシナリオ例を紹介している説明もあります。
アクセス制御 1
このセクションでは、それぞれのアクセス制御キャッシュについて説明します。アクセス
制御情報が最新であることは、ポータルの適切な運用に不可欠です。したがって、クラス
ターのすべてのメンバーにアクセス制御情報が伝搬するように、クラスターの中でアクセ
ス制御キャッシュを共有することが重要です。複数のキャッシュから情報を同時に再ロー
ドすることを避けるために、キャッシュごとに異なる存続時間を選択します。このように
存続時間と無効化間隔を比較的ランダムにしたパターンは、他のキャッシュにも適用でき
140
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ます。
アクセス制御キャッシュは 2 つのグループに分類できます。1 つは、すべてのポータル・
セットアップのすべてのアクセス制御操作で使用するもので、ここではこれを最初に説明
します。もう 1 つは、WebSphere Portal の複合アプリケーション・インフラストラクチャ
で使用するもので、cache com.ibm.wps.ac.ApplicationRoleOIDCache で始まる名前を持ちます。
1
こ の セ ク シ ョ ン の 内 容 は 、 一 部 を ホ ワ イ ト ペ ー パ ー 「 Portal Access Control
Performance
Tuning
」
（ http://www-128.ibm.com/developerworks/websphere/library/techarticles/0508_buehle
r/0508_buehler.html）から引用しています。
141
WEBSPHERE PORTAL 7.0 TUNING GUIDE
図 1 は、さまざまなキャッシュどうしの関係を示したものです。小さい円筒形はキャッシ
ュ・インスタンスを表しています。緑色のキャッシュは、ポータル・ユーザー管理（PUMA）
コンポーネントのキャッシュであり、ポータルのアクセス制御コンポーネントのキャッシ
ュと深く関連しているものです。PUMA キャッシュには、ユーザー・レジストリーから得
た情報が保存されます。ポータルのアクセス制御では、これらのキャッシュを使用してユ
ーザーを識別し、グループのメンバーシップを取得します。
縦軸はキャッシュの集約方向を表します。レイヤー N にあるキャッシュ・インスタンスは、
それぞれの値を計算する際に、レイヤー N よりも下位のレイヤーにあるキャッシュ・イン
スタンスを使用します。例えば、ポータルのアクセス制御コンポーネントでは、
ExplicitEntitlementsCache にキャッシュしたユーザーの実効的なアクセス権（資格）を計算
するときに、ChildResourcesCache および RoleMappingCache にある既存のキャッシュ値を
使用します。
図 2: ポータルのアクセス制御キャッシュの階層
com.ibm.wps.ac.PermissionCollectionCache
デ フ ォ ル ト の サ イ ズ : 2000 、 デ フ ォ ル ト の 存 続 時 間 : 10240 、 使 用 パ タ ー ン : 通 常
（admit-threshold）
このキャッシュには、アクセス権の確認に使用できるアクセス権のコレクションが保存さ
れます。このキャッシュのサイズは、システムに存在するアクセス権の数、つまりポータ
142
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ルのリソースの数とそれらに割り当てられているアクセス権の数に合わせて決まります。
多くの場合、このキャッシュにあるエントリーは、アクセス権の確認の際にきわめて頻繁
に要求されます。admit-threshold を使用して、使用頻度が低いアクセス権がキャッシュさ
れないようにしています。admit-threshold の設定を変更して、このキャッシュをチューニ
ングできます。このキャッシュでは、エントリーが無効化されません。必要な情報はすべ
てメモリーにあるので、キャッシュのエントリーの作成はきわめて迅速です。このキャッ
シュのエントリーは小型です。
143
WEBSPHERE PORTAL 7.0 TUNING GUIDE
com.ibm.wps.ac.AccessControlUserContextCache
デフォルトのサイズ: 8000、デフォルトの存続時間: 1200、使用パターン: 通常
このキャッシュは、アクセス制御のユーザー・コンテキスト・オブジェクトを保存します。
このオブジェクトは、特定のユーザーに割り当てられたアクセス権を収めたローカル・キ
ャッシュです。可能であれば、アクセス制御に対するすべての要求に対しては、このキャ
ッシュにある情報を使用して応答が処理されます。これにより、アクセス制御のメソッド
がきわめて短時間で戻ります。このキャッシュのサイズは、アクティブなユーザーの数に
合わせて決まります。動作が高速なポータルを実現するには、アクティブに作業している
すべてのユーザーのエントリー数に適したサイズのキャッシュとする必要があります。ユ
ーザーがアクセスできるポータル・リソースの数が多い場合は、特にこの点に注意します。
ポータルの管理アクションを実行すると、このキャッシュのエントリーは無効になります。
必要な情報はほとんどメモリーにあるので、このキャッシュの作成に要するコストは少な
いことが普通ですが、必要な情報が他のキャッシュに見つからない場合は時間を要するこ
とがあります。ユーザーがアクセスできるリソースの数によっては、このキャッシュのエ
ントリーのサイズがきわめて大きくなることがあります。
com.ibm.wps.ac.ProtectedResourceCache
デフォルトのサイズ: 5000、デフォルトの存続時間: 10143、使用パターン: 通常
このキャッシュには、ポータルのアクセス制御で保護しているリソースが保存されます。
このキャッシュのサイズは、システムのアクティブなユーザーがアクセスする保護された
リソースの数を基準とします。それぞれのアクセス権コール（資格コール）の際にアクセ
ス制御との対照を経て、このキャッシュからエントリーが読み取られます。
リソースの削除、リソースの再配置、リソースの状態（プライベート/共有）の変更、リソ
ースの所有者の修正、外部化、内部化、およびロール・ブロックの変更の際に、このキャ
ッシュのエントリーは無効になります。
キャッシュのエントリーを作成するには、ポータルのデータベースで単一行検索を実行す
る必要があります。このキャッシュのエントリーのサイズは比較的小型です。
com.ibm.wps.ac.OwnedResourcesCache
デフォルトのサイズ: 5000、デフォルトの存続時間: 10043、使用パターン: 無効化確認
このキャッシュでは、リソースの所有者（ユーザー・グループまたは個々のユーザー）を、
その所有リソースにマップします。このキャッシュのサイズは、アクティブなユーザー/グ
144
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ループの数に、それらのユーザー/グループがアクセスするリソース・タイプの数をかけた
数に合わせて決まります。
このキャッシュには、WebSphere Portal ドメイン別に、リソース・タイプごとのプリンシ
パルごとに 1 つのエントリーがあります。
多数のポータル・アクセス制御要求があったとき、その要求に対応する資格が資格キャッ
シュにまだキャッシュされていない場合は、このキャッシュからデータが読み取られます。
リソースの削除、リソース所有者の修正、外部化、およびユーザーのログアウトの際に、
このキャッシュのエントリーは無効になります。キャッシュ・エントリーの作成では、ポ
ータルのデータベースに対する複数行照会を実行する必要があります。このキャッシュの
エントリーのサイズは比較的小型です。
145
WEBSPHERE PORTAL 7.0 TUNING GUIDE
com.ibm.wps.ac.RolesCache
デフォルトのサイズ: 10000、デフォルトの存続時間: 3630、使用パターン: 無効化確認
このキャッシュにはロールのインスタンスが保存されます。このキャッシュのサイズは、
アクティブなユーザー/グループの数に、それらのユーザー/グループがアクセスするリソ
ース・タイプの数をかけた数に合わせて決まります。このキャッシュには、WebSphere Portal
ドメイン別に、リソース・タイプごとのプリンシパルごと、さらにロールのインスタンス
ごとに 1 つのエントリーがあります。多数のポータル・アクセス制御要求があったとき、
その要求に対応する資格が資格キャッシュにまだキャッシュされていない場合は、このキ
ャッシュからデータが読み取られます。ロールのマッピングの作成、ロールのマッピング
の削除、リソースの削除、外部化、内部化、およびユーザーのログアウトの際に、このキ
ャッシュのエントリーは無効になります。キャッシュ・エントリーを作成するには、少な
くとも 1 回のデータベース照会を実行する必要があります。この照会は複数回となること
もあります。このキャッシュのエントリーのサイズは比較的小型です。
com.ibm.wps.ac.ExplicitEntitlementsCache.* および
com.ibm.wps.ac.ChildEntitlementsCache
デフォルトのサイズ: 10000、デフォルトの存続時間: 可変（10000 前後）
、使用パターン: 無
効化
確認
これらのキャッシュには、同じリソース・タイプの多数のリソースに対するユーザーまた
はグループのアクセス権が保存されます。さまざまなリソース・タイプ向けに専用のキャ
ッシュがあります。例えば、ページ用のキャッシュは
com.ibm.wps.ac.
ExplicitEntitlementsCache.CONTENT_NODE という名前です。明示的に指定していないリソー
ス・タイプはすべてデフォルトのキャッシュに保存されます。このキャッシュのサイズは、
ポータルのナビゲーション中のリソースの使用またはポータルの管理でユーザー/グルー
プがアクセスするリソース・タイプのうち、このキャッシュで有効なものの数をアクティ
ブなユーザー/グループの数にかけた値に合わせて決まります。WebSphere Portal ドメイン
ごとのアクセス権のセットごとにエントリーが 1 つあります。エントリーの読み取りは、
通常のアクセス制御要求とページのレンダリングの際に発生するほか、特にポータルの管
理で多く発生します。特定のリソース・タイプを使用していない場合、それに対応するキ
ャッシュではキャッシュ・ミスのみが見られ、それ以外のアクティビティーは発生しませ
ん。すべてのアクセス制御の修正およびログインの際に、このキャッシュのエントリーは
無効になります。これらのキャッシュのいずれかに置くエントリーは、そのキャッシュよ
146
WEBSPHERE PORTAL 7.0 TUNING GUIDE
りも下位のキャッシュでメモリー内情報から作成できます。必要な情報が存在しない場合
は、キャッシュ・エントリーを作成するために複数のデータベース要求が必要になること
があります。このキャッシュのエントリーのサイズは比較的小型ですが、作成された複数
のオブジェクトは他のキャッシュに保存されることが普通です。
com.ibm.wps.ac.ExternalOIDCache
デフォルトのサイズ: 10000、デフォルトの存続時間: 8640、使用パターン: 通常
このキャッシュには、ページやポートレットの ID のような保護されている個々のリソース
の外部オブジェクト ID と、データベース表 PROT_RES に保存されている、ポータルのア
クセス制御固有のオブジェクト ID とのマッピングが保存されます。ポータルのアクセス制
御に対する多数の要求の際に、このキャッシュからエントリーが読み取られます。このキ
ャッシュのサイズは、システムのアクティブなユーザーがアクセスする保護されたリソー
スの数を基準とします。このマッピングは不変なので、このキャッシュが明示的に無効化
されることはありません。このキャッシュにエントリーを作成するには、単一行のデータ
ベース照会が必要です。このキャッシュのエントリーのサイズはかなり小型です。
147
WEBSPHERE PORTAL 7.0 TUNING GUIDE
com.ibm.wps.ac.groupmanagement.NestedGroupCache/
com.ibm.wps.ac.groupmanagement.GroupCache
デフォルトのサイズ: 1000、デフォルトの存続時間: 3600、使用パターン: 通常
WebSphere Portal をインストールした環境では、ネストしたグループの設定に応じてこれ
ら 2 つのキャッシュのいずれかのみが使用されます。ネストしたグループがサポートされ
ている場合は NestedGroupCache キャッシュが使用され、サポートされていない場合は
GroupCache が使用されます。これらのキャッシュには、ユーザーが属するネストしたグル
ープまたは直接グループが保存されます。このキャッシュのサイズは、アクティブなユー
ザーの数およびそれらのユーザーがアクセスする仮想ポータルの数に合わせて決まります。
ポータルへのログインでこのキャッシュへのアクセスが発生しますが、通常のポータル・
ナビゲーションではアクセスがないことが普通です。このキャッシュの主な用途は、ユー
ザーとユーザー・グループの管理です。ユーザーがログインしたときおよびユーザーとグ
ループの管理面の変更後に、このキャッシュのエントリーが無効になります。新しいキャ
ッシュ・エントリーを作成するには、WMM コンポーネントへの照会が必要で、多くの場合
は、それに続いてユーザー・レジストリーへの照会が必要です。このキャッシュのエント
リーのサイズは中程度です。
com.ibm.wps.ac.ChildResourcesCache
デフォルトのサイズ: 1000、デフォルトの存続時間: 7200、使用パターン: 通常
このキャッシュには、ポータルのアクセス制御にあるリソースの階層が保存されます。こ
のキャッシュのサイズは、保護されているリソースのキャッシュ同様に、システムのアク
ティブなユーザーがアクセスする保護されたリソースの数に合わせて決まります。アクセ
ス制御ツリーにあるリーフ・オブジェクトはこのキャッシュに保存されないので、キャッ
シュ・エントリーの数は少ないことが普通です。ポータルのアクセス制御に対するほとん
どの要求でこのキャッシュへのアクセスが発生します。リソースの削除、リソースの親の
変更、リソースの所有者の修正、外部化、内部化、およびロール・ブロックの変更の際に、
このキャッシュのエントリーは無効になります。キャッシュ・エントリーの作成では、ポ
ータルのデータベースに対する複数行照会が必要です。このキャッシュのエントリーのサ
イズはかなり小型です。
com.ibm.wps.ac.ApplicationRoleOIDCache
デフォルトのサイズ: 5000、デフォルトの存続時間: 7650、使用パターン: 通常
148
WEBSPHERE PORTAL 7.0 TUNING GUIDE
このキャッシュは、アプリケーション・ロール名を対応するオブジェクト ID にマップしま
す。このキャッシュのサイズは、システムで定義されているアプリケーション・ロールの
数に合わせて決まります。複合アプリケーションに対するアクセスや管理の際にこのキャ
ッシュから頻繁にデータが読み取られます。それ以外のすべての状況では、基本的にこの
キャッシュはまったく使用されません。アプリケーション・ロールを削除するとエントリ
ーは無効になります。このキャッシュには、カスタマイズ・ドメインを除く WebSphere Portal
ドメインごとのアプリケーション・ロールごとに 1 つのエントリーがあります。このキャ
ッシュにエントリーを作成するには、ポータル・データベースから単一行のデータを読み
取る必要があります。このキャッシュのエントリーはかなり小型です。
com.ibm.wps.ac.ApplicationRoleDescriptorCache
デフォルトのサイズ: 5000、デフォルトの存続時間: 8450、使用パターン: 通常
このキャッシュは、アプリケーション・ロールのオブジェクト ID をその対応する記述子オ
ブジェクトにマップします。この記述子オブジェクトには、アプリケーション名、親アプ
リケーション、およびその他の情報が収められています。このキャッシュのサイズは、シ
ステムで定義されているアプリケーション・ロールの数に合わせて決まります。複合アプ
リケーションに対するアクセスや管理の際にこのキャッシュから頻繁にデータが読み取ら
れます。
149
WEBSPHERE PORTAL 7.0 TUNING GUIDE
それ以外のすべての状況では、基本的にこのキャッシュはまったく使用されません。この
キャッシュにエントリーを作成するには、ポータル・データベースから単一行のデータを
読み取る必要があります。このキャッシュのエントリーのサイズは中程度です。
com.ibm.wps.ac.ApplicationRolesForPrincipalCache
デフォルトのサイズ: 5000、デフォルトの存続時間: 8760、使用パターン: 通常
このキャッシュは、使用可能なアプリケーション・ロールをポータル・ユーザーにマップ
します。このキャッシュのサイズは、システムのアクティブなユーザーの数に合わせて決
まります。複合アプリケーションに対するアクセスや管理の際にこのキャッシュから頻繁
にデータが読み取られます。また、アプリケーション・ロールを使用していない場合でも、
アプリケーション・ロール情報のルックアップとしてこのキャッシュが使用されます。し
たがって、すべての状況下でこのキャッシュに対する読み取りアクセスが頻繁に発生しま
す。キャッシュ・エントリーの作成は、比較的高いコストが発生する処理です。その際は、
3 つの WebSphere Portal ドメインに対する 3 回の複数行照会が必要です。このキャッシ
ュのエントリーのサイズは中程度です。
com.ibm.wps.ac.ContainedRolesCache
デフォルトのサイズ: 5000、デフォルトの存続時間: 8650、使用パターン: 通常
このキャッシュには、アプリケーション・ロールとそこで定義されている通常のロールと
のマッピングが保存されます。このキャッシュのサイズは、システムにあるアプリケーシ
ョン・ロールの数に合わせて決まります。WebSphere Portal ドメインごとに 1 つのエント
リーがあります。複合アプリケーションに対するアクセスや管理の際にこのキャッシュか
ら頻繁にデータが読み取られます。それ以外のすべての状況では、基本的にこのキャッシ
ュはまったく使用されません。キャッシュ・エントリーの作成は、比較的高いコストが発
生する処理です。その際には、2 回の複数行照会が必要です。このキャッシュのエントリ
ーのサイズは中程度です。
com.ibm.wps.ac.ApplicationRoleChildrenCache
デフォルトのサイズ: 5000、デフォルトの存続時間: 8760、使用パターン: 通常
WebSphere Portal V7.0 ではこのキャッシュを使用しません。
150
WEBSPHERE PORTAL 7.0 TUNING GUIDE
com.ibm.wps.ac.ParentResourceRoleMappingCache および
com.ibm.wps.ac.ResourceRoleMappingCache
デフォルトのサイズ: 1000、デフォルトの存続時間: 無制限、使用パターン: 通常
この 2 つのキャッシュは特殊なアクセス制御のシナリオで使用するもので、ポータルの処
理では普通はアクセスされません。これらのキャッシュの設定は変更しないようにします。
ポータル・ユーザー管理
ポータル・ユーザー管理コンポーネント（PUMA）では次のキャッシュを使用します。その
範囲では、これらのキャッシュはアクセス制御キャッシュと WMM でのキャッシングに深
く関係しています。
com.ibm.wps.puma.DN_OID_Cache/com.ibm.wps.puma.OID_DN_Cache
デフォルトのサイズ: 1500、デフォルトの存続時間: 無制限、使用パターン: 通常
これらの 2 つのキャッシュには、ユーザーおよびグループの識別名とその内部オブジェク
ト ID 識別子とのマッピングが保存されます。これらのキャッシュのサイズは、アクティブ
なユーザーとグループの数または委任で使用するユーザーとグループの数に合わせて決ま
ります。ユーザーまたはグループの委任の際に、このキャッシュのエントリーは無効にな
ります。エントリーの作成では 1 回のデータベース検索が必要です。これらのキャッシュ
のエントリーのサイズはかなり小型です。
151
WEBSPHERE PORTAL 7.0 TUNING GUIDE
データストア
データストア・キャッシュにはポータル・データベースから読み取ったデータが保存され
ます。これらのキャッシュの目的は、データベースの内容の完全なイメージとなることで
はなく、頻繁にアクセスされるロー情報を他のすべてのポータル・コンポーネントで使用
できるようにすることです。
com.ibm.wps.datastore.services.Identification.OidAndUniqueName.cache
デフォルトのサイズ: 5000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには固有の名前が保存されます。このキャッシュは、ページのレンダリン
グと、特に固有の名前の管理できわめて頻繁に使用されます。ページとポートレットの固
有の名前が、このキャッシュでは最大の内容を占めます。このキャッシュのサイズは、関
連付けられた固有の名前を持つ、使用頻度がきわめて高いページとポートレットのエント
リーを保持するうえで十分なものであることが必要です。すべてのリソースに、それに関
連付けられた固有の名前があるわけではありません。データベース検索が発生しないよう
にするには、データベース表の UNIQUE_NAME に 2 をかけた値に対応するキャッシュ・サ
イズとして、2 方向のマッピングができるようにします。キャッシュ・エントリーの作成
では、ポータル・データベースからエントリーを 1 つ読み取る必要があります。このキャ
ッシュのエントリー・オブジェクトはかなり小型です。
com.ibm.wps.datastore.PortalIdCache.vpPerLpid.cache
デフォルトのサイズ: 1000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュは、長い仮想ポータル・オブジェクト ID をポータル内部の短い ID にマッ
プします。キャッシュ・サイズは、システムにある仮想ポータルの数に追加のエントリー 1
つを加算した値に合わせて決まります。システムに複数の仮想ポータルが存在する場合に
のみ、このキャッシュが多用されます。その場合は、レンダリング要求ごとにこのキャッ
シュからデータが読み取られます。最適なキャッシングを実現するには、キャッシュ・サ
イズを、システムで定義している仮想ポータルの数に設定する必要があります。このキャ
ッシュにエントリーを作成するには、1 回の単一行データベース検索が必要です。このキ
ャッシュのエントリー・オブジェクトはかなり小型です。
com.ibm.wps.datastore.PortalIdCache.explicitLpidPerVP
デフォルトのサイズ: 100、デフォルトの存続時間: 無制限、使用パターン: 通常
152
WEBSPHERE PORTAL 7.0 TUNING GUIDE
このキャッシュは、仮想ポータルの短いオブジェクト ID を、対応する長い ID にマップし
ます。com.ibm.wps.datastore.PortalIdCache.vpPerLpid.cache キャッシュとは逆方向のマッピ
ングを保存します。したがって、その点を除けば、上記の説明がすべてこのキャッシュに
も当てはまります。
com.ibm.wps.datastore.pageinstance.OIDCache
デフォルトのサイズ: 3000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、ログインやページ・ナビゲーションの際に情報を迅速に取得できる
ように、ポータル・ページに関する情報が保存されます。このキャッシュのサイズは、シ
ステムにあるページのインスタンス数に合わせて決まります。最も頻繁に使用されるキャ
ッシュの 1 つなので、ユーザーが頻繁にアクセスするすべてのページを保持できるサイズ
であることが必要です。直接ナビゲーション、他のページへのリンクの作成、またはポー
タル管理中（必ずより高い派生レベルを扱う管理）のページでの作業によってページがロ
ードされ、キャッシュに保存されます。このキャッシュにエントリーを作成するには、1 回
の単一行データベース検索が必要です。このキャッシュのエントリーのサイズは中程度で
す。キャッシュのヒット率の点から最高のパフォーマンスを実現するには、キャッシュ・
サイズを、システムで定義しているすべてのページを保存できるサイズに設定する必要が
あります。このサイズは、データベース表 PAGE_INST の行数に相当します。
153
WEBSPHERE PORTAL 7.0 TUNING GUIDE
com.ibm.wps.datastore.pageinstance.DerivationCache
デフォルトのサイズ: 3000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、ページとその派生した子ページとのマッピングが保存されます。そ
のような子ページが存在しない場合は空のマッピングが保存されます。
pageinstance.OIDCache 同様に、ページのレンダリングと管理で頻繁にアクセスされます。
このキャッシュにエントリーを作成するには、1 回の複数行データベース照会が必要です。
このキャッシュのサイズも、システムにあるページの数に合わせて決まります。したがっ
て、この前に説明したキャッシュと同じサイズを使用できます。ポータルを使用するシナ
リオの大半では、このキャッシュの実際のサイズは、ページ・インスタンス・キャッシュ
よりもいくらか小さい値になります。このキャッシュのエントリーの平均サイズは比較的
小型です。派生した子の長いリストがすべてのページにある場合にのみ、エントリー・サ
イズが大きくなります。キャッシュのヒット率の点から最高のパフォーマンスを実現する
には、キャッシュ・サイズを、システムで定義しているすべてのページを保存できるサイ
ズに設定する必要があります。このサイズは、データベース表 PAGE_INST の行数に相当し
ます。
com.ibm.wps.datastore.pageinstance.DynamicNodeCache
デフォルトのサイズ: 5、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、ドメインごとに 1 つのリストが保存されます。これらのリストには、
対応するドメインの中で動的ノードとしてフラグ指定されたすべてのページが保存されて
います。つまり、動的なアセンブリー・コンテンツ・ノードはこれらのページの下に追加
できます。ドメインの数が増加することはないので、このキャッシュでは、サイズとその
他のプロパティーを変更しないようにします。このキャッシュのエントリーのサイズは、
動的ノードがほとんどないポータルの場合は小さく、システムに多数の動的ノードが存在
する場合は中程度にまで及びます。
com.ibm.wps.datastore.services.Identification.SerializedOidString.cache
デフォルトのサイズ: 2500、デフォルトの存続時間: 無制限、使用パターン: オブジェクト・
タイプのカスケード
このキャッシュには、要求のパラメーターまたは XML Access ファイルで使用する直列化
したオブジェクト ID が保存されます。これには、メモリーにロード済みのすべてのオブジ
ェクト ID のサブセットが含まれます。その限りでは、システムにあるオブジェクト ID の
154
WEBSPHERE PORTAL 7.0 TUNING GUIDE
数に合わせてキャッシュ・サイズが決まりますが、直列化したバージョンが要求されるこ
れらの ID がすべて対象となるわけではないので、実際のサイズは予測できません。このキ
ャッシュは、すべての要求で使用されます。キャッシュ・エントリーの作成は、比較的低
コストで済む処理です。普通はすべての情報をメモリーに取得できるので、データベース
の検索はほとんど不要です。このキャッシュのエントリーはかなり小型です。
155
WEBSPHERE PORTAL 7.0 TUNING GUIDE
モデル
モデル・キャッシュは 2 つのグループに分類できます。1 つは、ページのレンダリング中
の各ポータル要求でアクセスされるキャッシュのグループです。もう 1 つのグループは、
管理アクションで特に重要なキャッシュのグループです。したがって、コンテンツとポー
タルの管理を実施する環境では、これらのキャッシュが特に重要になります。ほとんどの
実行時キャッシュは名前のサフィックスとして live を持ち、管理キャッシュはサフィック
スとして isolated を持ちます。
図 29 は、モデル・コンポーネントおよび依存するポータル・コンポーネントでのキャッ
シュの階層を示したものです。この図の構造は図 28 と同じです。縦軸は、データの集約
が増加する方向にキャッシュを示しています。モデル・コンポーネントでは、比較的高い
集約レベルでのみデータをキャッシュします。したがって、ここでキャッシュするデータ
はすべて比較的価値の高いものであり、対応するデータが下位のキャッシュにないと、再
ロードはコストの高い処理になります。モデル・キャッシュは、データストアとポータル
のアクセス制御キャッシュに依存しています。この図では、重要性が高いキャッシュのみ
を取り上げています。
図 3: ポータル・モデルのキャッシュの階層
com.ibm.wps.model.factory.SimpleCacheKey
デフォルトのサイズ: 2500、デフォルトの存続時間: 無制限、使用パターン: 通常
156
WEBSPHERE PORTAL 7.0 TUNING GUIDE
このキャッシュは、ポータル・モデル・ファクトリーで使用する他のモデル・キャッシュ
のヘルパー・キャッシュです。ポータルで使用できるモデル・タイプに基づいて少数のエ
ントリーが保存されています。さらに、アクティブなユーザー・セッションごとにエント
リーを 1 つ追加できます。このキャッシュのサイズは、1 つのポータル JVM にあるアク
ティブなセッションの数に適応して設定できます。キャッシュ・エントリーの再作成は、
メモリー内で実行できることが普通なので、低コストで済みます。このキャッシュのエン
トリーは小型のオブジェクトです。
157
WEBSPHERE PORTAL 7.0 TUNING GUIDE
com.ibm.wps.model.content.impl.ResourceCache
デフォルトのサイズ: 5000、デフォルトの存続時間: 5600、使用パターン: 通常
このキャッシュには、集約したページが保存されます。データ・ストア・ページ・インス
タンス・キャッシュと異なり、このキャッシュに保存する内容は、ページのすべてのモデ
ルとそのコンテンツ（ポートレットとコンテナー）です。このページ・インスタンス・キ
ャッシュでは、主にロー・ページ・データを保持します。このキャッシュのサイズは、ポ
ータルで定義されているページの数およびそれらのページに設定されているアクセス制御
権限のそれぞれ異なるセットの数を基準とします。このキャッシュはきわめて貴重な情報
を保存します。このキャッシュでは、ページ・インスタンス・キャッシュやアクセス制御
キャッシュなどの他のキャッシュをいくつか使用して、キャッシュのデータを作成します。
したがって、キャッシュ・エントリーの作成ではメモリーにある情報のみを必要とするこ
とが普通ですが、多数のデータベース照会が発生することもあります。キャッシュのエン
トリーのサイズはページの複雑さに左右されますが、普通は、キャッシュされている他の
データへの参照で構成されていることから、多くの場合は中程度のサイズのオブジェクト
になります。このキャッシュには、最も頻繁にアクセスされるページの数にそれらのペー
ジにあるアクセス制御設定の数をかけた数のエントリーを保持できる必要があります。ペ
ージの定義が頻繁に変化しない環境であれば、キャッシュの存続時間を長くすると効果的
です。
例:500 ページで構成するポータルがあり、これらのページに対してすべてのユーザーが同
じアクセス権を持っているとします。また、別に 50 ページがあり、これらのページに対
しては 2 つのユーザー・グループがそれぞれ異なるアクセス権を持っています。この場合
は、最大で 600 件のエントリーがこのキャッシュに存在します。
com.ibm.wsp.mode.content.impl.TopologyCache
デフォルトのサイズ: 10000、デフォルトの存続時間: 5700、使用パターン: 通常
このキャッシュにはポータルのトポロジー情報が保存されます。この情報とは、ナビゲー
ション・ノードおよびソートしてアクセス制御でフィルター処理したその子ノードで構成
するポータル・ナビゲーション要素です。トポロジー要素は、データベースからロードさ
れた時点からいくつかの処理手順を経て、最終的にキャッシュに追加されます。このキャ
ッシュには、完全に処理したトポロジー・エンティティーのみが保存されます。ユーザー
がログインするときやポータルの中で同じセッションではまだ使用したことがない部分に
ナビゲートするときは、このキャッシュが明示的に使用されます。キャッシュのエントリ
158
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ーが見つからない場合は、専用のコピーが作成され、以降はそれが処理されます。すべて
のナビゲーション・ノードで完全な処理が実行されるわけではありませんが、完全に処理
された専用のコピーはキャッシュに追加されます。キャッシュにあるエントリーをユーザ
ーが見つけると、そこへの参照がユーザーの専用トポロジー・モデルにコピーされるので、
キャッシュにはそれ以上アクセスする必要がなくなります。したがって、ユーザーとナビ
ゲーション・ノードごとに 1 回のヒット（またはミス）のみが発生します。このキャッシ
ュのサイズは、ナビゲーション・ノードの数とそれらのノードに対するアクセス権のそれ
ぞれ異なるセットの数を基準とします。これは、多くの場合、ページが属する派生チェー
ン（子および親）の数です。このキャッシュのエントリー作成はコストを要する処理です。
作成するエントリーには、アクセス制御キャッシュやページ・インスタンス・キャッシュ
などのキャッシュされている他の情報が必要です。このキャッシュのエントリーは中程度
のサイズを持ち、主にキャッシュされている他のデータへの参照のリストです。最も重要
なページの数にこれらのページに存在するアクセス権のそれぞれ異なるセットの数をかけ
た数のエントリーを保存できるように、このキャッシュのサイズを設定する必要がありま
す。
159
WEBSPHERE PORTAL 7.0 TUNING GUIDE
com.ibm.wps.model.factory.ContentModelCache.live
デフォルトのサイズ: 1000、デフォルトの存続時間: 無制限、使用パターン: 通常
この実行時キャッシュには、ポータル・ユーザーのコンテンツ・モデルが保存されます。
アクティブなポータル・ユーザーごとにエントリーが 1 つあります。このキャッシュには、
これらユーザーのすべてのモデルを保持できるサイズが必要です。このキャッシュのエン
トリーの存続時間は、対応するユーザー・セッションの最大存続時間です。つまり、セッ
ションが終了するとエントリーは削除されます。このキャッシュのエントリー作成はきわ
めてコストの高い処理です。必要な情報はすべてメモリーにあることが普通ですが、基礎
となる情報がキャッシュに存在しない場合は、データベースへの多数回のアクセスが必要
になることがあります。さらに、膨大な数のページがモデルに要約されていることがあり、
その場合はキャッシュ・エントリーの作成に要する時間がさらに長くなります。コンテン
ツ・モデルは、最新の要求で必要になるたびにサイズを増やしながら作成されるものであ
り、一度に作成されるものではありません。モデルのサイズに応じて、メモリーの要件も
変化します。ユーザーがアクセスできるページが多いほど、また現在のセッションでユー
ザーがアクセスしているページが多いほど、キャッシュ・エントリーは大きくなり、中程
度からきわめて大型にまで及びます。キャッシュ・エントリーは、キャッシュされている
他のオブジェクトや共有している他のオブジェクトへの参照で構成されていることが普通
です。したがって、エントリーのサイズは、ページとすべての従属オブジェクトの数では
なく、これらへの参照の数で決まります。
com.ibm.wps.model.factory.ContentModelCache.isolated
デフォルトのサイズ: 1000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、管理コンテンツ・モデルが保存されます。特定の時点で管理作業を
実行するすべてのユーザーごとに 1 つのエントリーがあります。その範囲では、このキャ
ッシュのエントリー数は、他のキャッシュに比べるとはるかに少ないことが普通です。た
だし、このキャッシュでは、アクティブなユーザーのキャッシュ・エントリーが除外され
ないようにする必要があります。他のすべての情報については、コンテンツ・モデルの実
行時キャッシュと比較してください。
com.ibm.wps.model.factory.NavigationSelectionModelCache.live
デフォルトのサイズ: 1000、デフォルトの存続時間: 無制限、使用パターン: 通常
この実行時キャッシュには、ポータル・ユーザーが使用するナビゲーション選択モデルが
160
WEBSPHERE PORTAL 7.0 TUNING GUIDE
保存されます。ユーザー・セッションごとに 1 つのエントリーがあります。このキャッシ
ュには、アクティブなユーザーのすべてのモデルを保持できるサイズが必要です。このキ
ャッシュのエントリーの存続時間は、対応するユーザー・セッションの最大存続時間です。
つまり、セッションが終了するとエントリーは削除されます。コンテンツ・モデルのエン
トリー作成に比べると、このキャッシュのエントリー作成は低コストの処理です。普通は、
必要とするすべての情報がメモリーにありますが、データベースへのアクセスが必要にな
ることもあります。コンテンツ・モデル・キャッシュに比べると、ナビゲーション選択モ
デル・キャッシュでのエントリー作成ははるかに低コストです。また、このタイプのモデ
ルはオブジェクトをほとんど参照しないので、このキャッシュの要素がメモリーに占める
サイズもはるかに小さくなっています。
com.ibm.wps.model.factory.NavigationSelectionModelCache.isolated
デフォルトのサイズ: 1000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、管理ユーザーが使用するナビゲーション選択モデルが保存されます。
管理コンテンツ・モデル・キャッシュに関する詳細は、このキャッシュにも当てはまりま
す。
161
WEBSPHERE PORTAL 7.0 TUNING GUIDE
com.ibm.wps.model.factory.URLMappingCache.live
デフォルトのサイズ: 50、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュは、ポータルのインストール環境で定義した URL マッピングの実行時モデ
ル・キャッシュです。システムで定義しているすべての URL マッピングを保持できるサイ
ズのキャッシュであることが必要です。このキャッシュにエントリーを作成するには、ポ
ータル・データベースからエントリーを 1 つ読み取る必要があります。このキャッシュの
エントリーはかなり小型です。
com.ibm.wps.model.factory.URLMappingCache.isolated
デフォルトのサイズ: 50、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュは、URL マッピングの管理キャッシュです。他の isolated キャッシュに関
する詳細は、このキャッシュにも当てはまります。
com.ibm.wps.model.factory.MultiModelCache.live
デフォルトのサイズ: 50、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、WebSphere Portal にあるいくつかのリソース・タイプの実行時モデ
ルが保存されます。このようなリソースとして、クライアント、サポート対象のマークア
ップと言語などがあります。例えば、サポートされているすべてのマークアップのリスト
が 1 つのエントリーになります。これらのリソースは長期間変化せずに存続していること
が普通なので、このキャッシュに対するアクセスはほとんど読み取りアクセスです。この
キャッシュのエントリー作成では、データベースから該当のデータを読み取る必要があり
ます。エントリーはかなり大きくなることがありますが、その数はきわめて少ないので、
このキャッシュの合計サイズは無視できます。
com.ibm.wps.model.factory.MultiModelCache.isolated
デフォルトのサイズ: 1000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、ポータルにあるいくつかのリソース・タイプの管理モデルが保存さ
れます。このようなリソース・タイプの管理は滅多に発生しないので、ほとんどの場合、
このキャッシュは空で、使用されません。キャッシュに保存するリソース・タイプの管理
を実行するユーザーごとに 1 つのエントリーがあります。エントリー作成の動作とエント
リーのサイズは実行時キャッシュと同等です。
162
WEBSPHERE PORTAL 7.0 TUNING GUIDE
com.ibm.wps.model.factory.NavigationModelCache.live
デフォルトのサイズ: 2、デフォルトの存続時間: 無制限
このキャッシュは、WebSphere Portal V7.0 では使用しないので無効になっています。その
プロパティーを変更しても何も効果はありません。
com.ibm.wps.model.factory.NavigationModelCache.isolated
デフォルトのサイズ: 2、デフォルトの存続時間: 無制限
このキャッシュは、WebSphere Portal V7.0 では使用しないので無効になっています。その
プロパティーを変更しても何も効果はありません。
163
WEBSPHERE PORTAL 7.0 TUNING GUIDE
com.ibm.wps.model.content.impl.DynamicLoadCache
デフォルトのサイズ: 4、デフォルトの存続時間: 600.
このキャッシュは、WebSphere Portal V7.0 では使用しないので無効になっています。その
プロパティーを変更しても何も効果はありません。
com.ibm.wps.model.impl.RuntimeClientMap.userAgent2client
デフォルトのサイズ: 1000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュは、ユーザー・エージェント・ストリング、つまり HTTP ヘッダーでブラ
ウザーから送信された識別ストリングをクライアントのプロファイルにマップします。こ
れらのプロファイルは、基本的に CC/PP プロファイルに対応しています。したがって、
このキャッシュのサイズはブラウザーの識別ストリングの数を基準としています。このキ
ャッシュにあるデータに対しては、要求ごとにアクセスが発生します。プロファイルの情
報はメモリーにあるので、キャッシュのエントリーの作成はきわめて低コストです。キャ
ッシュのエントリーは、既存のデータを参照するだけなので、かなり小型です。
URL マッピング
ここで挙げるキャッシュには、ポータルの URL マッピングに関するデータが保存されます。
システムで定義しているすべての URL マッピングを保持できるサイズのキャッシュとす
る必要があります。
wps.mappingurl.ContextsCache
デフォルトのサイズ: 500、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、URL マッピングのコンテキストが保存されます。このキャッシュの
サイズは、システムで定義されているマッピング・コンテキストの数を基準とします。ル
ックアップ・キャッシュを使用して URL マッピングを解決できない場合はこのキャッシュ
が使用されます。エントリーの作成では、データベースからマッピング・エントリーを読
み取る必要があります。このキャッシュのエントリーのサイズは中程度です。
wps.mappingurl.LookupCache
デフォルトのサイズ: 600、デフォルトの存続時間: 無制限、使用パターン: 通常
164
WEBSPHERE PORTAL 7.0 TUNING GUIDE
このキャッシュは、URL マッピング（の階層）と WebSphere Portal リソースとの計算済み
マッピングを保存する最終的なルックアップ・キャッシュとして使用します。着信 URL を
分析して URL マッピングとするときの要求ごとにこのキャッシュへのアクセスが発生し
ます。このキャッシュのサイズは、すべてのマッピングの数とする必要があります。所要
の情報はメモリーにあるので、一般的にこのキャッシュ・エントリーの作成は低コストで
す。このキャッシュ・エントリーのサイズは比較的小型です。
仮想ポータル
ここで挙げるグループのキャッシュは、追加の仮想ポータルを定義しているシステムにの
み関係があります。他のすべての状況では、これらのキャッシュのサイズを 1、存続時間
を無制限に設定しておけば問題ありません。
165
WEBSPHERE PORTAL 7.0 TUNING GUIDE
com.ibm.wps.services.vpmapping.VirtualPortalIDToRealmCache
デフォルトのサイズ: 120、デフォルトの存続時間: 3600、使用パターン: 通常
このキャッシュには、仮想ポータルのレルム情報が保存されます。1 つのレルムには複数
の仮想ポータルを保存できますが、1 つの仮想ポータルが複数のレルムに属することはで
きません。その結果、このキャッシュの最適なサイズは、環境で定義されている仮想ポー
タルの数になります。仮想ポータルのセットアップを変更する頻度が低い場合は、存続時
間を長くしてパフォーマンスの向上を図ることができます。デフォルトのポータルのみを
使用し、追加の仮想ポータルを設定しない場合、このキャッシュのエントリーは 1 つのみ
で、キャッシュのトラフィックはほとんど発生しません。このキャッシュに新しいエント
リーを作成するには、1 回のデータベース照会が必要です。このキャッシュのエントリー
のサイズはかなり小型です。
com.ibm.wps.services.vpmapping.VirtualPortalIDToURLCache
デフォルトのサイズ: 120、デフォルトの存続時間: 3600、使用パターン: 通常
このキャッシュは、仮想ポータルの ID をそれぞれの LPID にマップします。通常、LPID は
特定の仮想ポータルの URL を作成するために使用します。LPID の数は仮想ポータルの ID
の数に等しいので、このキャッシュの最適なサイズは、環境に定義されている仮想ポータ
ルの数です。仮想ポータルのセットアップを変更する頻度が低い場合は、存続時間を長く
してパフォーマンスの向上を図ることができます。デフォルトのポータルのみを使用し、
追加の仮想ポータルを設定しない場合、このキャッシュのエントリーは 1 つのみで、キャ
ッシュのトラフィックはほとんど発生しません。
com.ibm.wps.services.vpmapping.URLToVirtualPortalIDCache
デフォルトのサイズ: 120、デフォルトの存続時間: 3600、使用パターン: 通常
このキャッシュは、LPID の値を仮想ポータルの ID にマップします。LPID は、特定の仮
想ポータルを指す URL にエンコードされます。したがって、LPID の数は仮想ポータルの
ID の数と同じです。その結果、このキャッシュの最適なサイズは、環境で定義されている
仮想ポータルの数になります。仮想ポータルのセットアップを変更する頻度が低い場合は、
存続時間を長くしてパフォーマンスの向上を図ることができます。デフォルトのポータル
のみを使用し、追加の仮想ポータルを設定しない場合、このキャッシュのエントリーは 1
つのみで、キャッシュのトラフィックはほとんど発生しません。
166
WEBSPHERE PORTAL 7.0 TUNING GUIDE
WSRP
すべての WSRP キャッシュへのアクセスは、ポータルが WSRP コンシューマーまたはプ
ロデューサーとして使用されている場合のみ発生します。各キャッシュは、WSRP 通信の
いずれかの側で使用されますが、両側では使用されません。ほとんどの WSRP キャッシュ
は、提供されているポートレットのあるページを表示しているか、WSRP プロパティーを
管理しているそれぞれの WSRP 要求の際に使用され読み取られます。この一般的なルール
の例外を次に示します。
167
WEBSPHERE PORTAL 7.0 TUNING GUIDE
wsrp.cache.portletdescription
デフォルトのサイズ: 500、デフォルトの存続時間: 3600、使用パターン: 通常
このキャッシュには、プロデューサーによって提供されるポートレットの説明が保存され
ます。これらの説明は、言語や説明など、提供されるポートレットのメタ情報と見なすこ
とができます。プロデューサー側で使用されます。このキャッシュのサイズは、プロデュ
ーサーによって提供されるリモート・ポートレットの数に合わせて決まります。提供され
るポートレットの説明をあまり変更しない場合、デフォルトの存続時間を増やすとパフォ
ーマンスを改善することができます。 キャッシュのエントリーの再生成は、比較的高いコ
ストが発生する処理です。これには、いくつかのコールのあるデータベースからのデータ
のロードが含まれています。キャッシュ・エントリーは、メモリー使用量の点で比較的高
いコストが発生する処理です。
wsrp.cache.servicedescription
デフォルトのサイズ: 150、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、WSRP プロデューサーのサービス説明が保存されます。コンシュー
マー側で使用されます。このキャッシュのサイズは、コンシュームするポータルに統合さ
れた WSRP プロデューサーの数に合わせて決まります。プロデューサー・ポータルからの
すべてのポートレットの説明と追加データを使用して、サービスの説明が生成されます。
したがって、サービスの説明はメモリー要件の点から大容量になる可能性があります。説
明の再作成にはいくつかの往復処理が必要で、コストの高い操作です。ユーザーが WSRP
管理ポートレットで「参照」ボタンをクリックすると、キャッシュ・エントリーが再作成
されます。これにより、全プロデューサーのすべてのサービスの説明がリフレッシュされ
ます。このキャッシュは、WSRP 管理中にのみ使用されます。
wsrp.cache.portlet.instance
デフォルトのサイズ: 2500、デフォルトの存続時間: 3600、使用パターン: 通常
このキャッシュには、WSRP コンシューマー側のプロキシー・ポートレット・インスタン
スが保存され、ここでのみ使用されます。このキャッシュのサイズは、統合リモート・ポ
ートレットの数と、そのリモート・ポートレットのポートレット・プリファレンス (レガシ
ー・ポートレットの各ポートレット設定) を独自にカスタマイズしたユーザー数を乗算した
数に合わせて決まります。キャッシュ・エントリーの作成には、複数行のデータベース照
会が含まれます。キャッシュされたエントリーのサイズは、ポートレットと関連するパラ
メーター数によって変化します。したがって、サイズは小さい場合もかなり大きい場合も
168
WEBSPHERE PORTAL 7.0 TUNING GUIDE
あります。
wsrp.cache.producer.user
デフォルトのサイズ: 5000、デフォルトの存続時間: 3600、使用パターン: 複数オブジェク
ト・タイプ
このキャッシュには、プロデューサーの説明とユーザーとプロデューサーとの間のコンテ
キスト情報が保存されます。コンシューマー側で使用されます。このキャッシュのサイズ
は、これらのプロデューサーのリモート・ポートレットにアクセスしているアクティブ・
ユーザーの合計数 (つまり、最大でプロデューサーの数とリモート・ポートレットにアクセ
スしているアクティブ・ユーザーを乗算した数に、プロデューサー数を加えたもの) に合わ
せて決まります。キャッシュのエントリーの再生成は、かなり高いコストが発生する処理
です。これには、DB 照会とメモリー内操作が含まれています。したがって、セッション・
タイムアウトはキャッシュ内にあるエントリーの存続時間よりも長くなることはありませ
ん。キャッシュ・エントリーは、ユーザー・セッションの消滅時には明示的に無効化され
ています。
169
WEBSPHERE PORTAL 7.0 TUNING GUIDE
wsrp.cache.portlet.window
デフォルトのサイズ: 2500、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、WebSphere Portal ポートレットのエントリー・オブジェクトにある
WSRP 固有ラッパーが保存されます。プロデューサー側で使用されます。このキャッシュ
のサイズは、提供されるポートレットの数とコンシューマー・ページにあるこれらのポー
トレットの発生数に合わせて決まります。キャッシュ・エントリーの再作成に要するコス
トは比較的少なく、一般的にメモリー内処理のみが含まれています。このキャッシュのエ
ントリーのサイズはかなり小型です。このキャッシュは、要求時には頻繁にアクセスされ
ます。
wsrp.producer.portletpool.pops
デフォルトのサイズ: 1000、デフォルトの存続時間: 無制限、使用パターン: オブジェクト・
タイプのカスケード
このキャッシュには、プロデューサーの提供するポートレットが保存されるので、キャッ
シュのサイズはそのポートレットの数に合わせて決まります。このキャッシュ内のエント
リー数は、portletdescription キャッシュ内のエントリー数と等しくなります。しかし、WSRP
オブジェクト・モデル・データはここに保存されます。まず提供されるポートレットがこ
のキャッシュ内で検索され、検索されなかった場合、ccps キャッシュ内が検索されます (下
記参照)。キャッシュ・エントリーの再ロードには、データベースに対する 1 照会が含まれ
ます。このキャッシュのエントリーは比較的小型です。
wsrp.producer.portletpool.ccps
デフォルトのサイズ: 1000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、クライアントの構成したポートレットが保存されます。プロデュー
サー側で使用されます。このキャッシュのサイズは、提供されるポートレットの数と、そ
れらのポートレットをパーソナライズしたリモート・ユーザー (コンシューマー構成ポート
レット) の数に合わせて決まります。したがってこの最大数は、提供されたポートレット数
に、プロデューサーへアクセスしているリモート・ユーザーの数を乗算したものになりま
す。キャッシュ・エントリーの再ロードには、データベースに対する 1 照会が含まれます。
このキャッシュのエントリーは比較的小型です。
170
WEBSPHERE PORTAL 7.0 TUNING GUIDE
動的アセンブリー / プロセス統合
次のキャッシュは、動的 UI 機能の使用時に使われ、WebSphere Process Server 統合と共に
使用されることもよくあります。
processintegration.PendingTasksCache
デフォルトのサイズ: 2500、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、ユーザー範囲にある保留中のプロセス・タスクが保存されます。こ
のキャッシュのサイズは、現在プロセス統合機能を使用しているユーザーの数に合わせて
決まります。各キャッシュ・エントリーには、指定ユーザーの保留プロセス・タスクの全
セットが保存されるので、メモリーがかなり大型になる可能性があります。キャッシュ・
エントリーの再ロードには、EJB コールを介したヒューマン・タスク・マネージャーへの
アクセスも含みます。このキャッシュは、PendinｇTasksTag がポートレット JSP で使用
される際に常にアクセスされます。
デ フ ォ ル ト の 値 を
30
秒 に し て
ConfigServices.properties
内 に 設 定
processintegration.pendingtasks.lifetime も構成します。この設定は、ユーザーによる保留タ
スクに対してプロセス・エンジンが照会され、キャッシュ・エントリーが更新される間隔
を表します。
171
WEBSPHERE PORTAL 7.0 TUNING GUIDE
wp.te.transformationAssociationCache
デフォルトのサイズ: 500、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには変換拡張ノードが保存されます。したがって、一般的にキャッシュ内
には少しのエントリーしかありません。一般的に 1 要求に対するキャッシュへのアクセス
は 1 回です。キャッシュ内へのエントリーの作成には、1 つのデータベース照会が含まれ
ます。1 エントリーはかなり小型です。一般的にこのキャッシュの設定は変更不要です。
ポリシー
WebSphere Portal のポリシー・マネージャーは、次のキャッシュを使用します。
com.ibm.wps.policy.services.PolicyCacheManager
デフォルトのサイズ: 1000、デフォルトの存続時間: 7780、使用パターン: 通常
このキャッシュには、ポリシーが保存されます。初期設定のポータルには、12 のテーマ・
ポリシーと 1 つのメール・ポリシーがあり、ポリシーごとに 1 エントリーがキャッシュ
に保存されます。したがって、キャッシュ・エントリーの最大数はシステムとカスタム・
ポリシー数によって変化します。ポリシーを常時使う場合このキャッシュにはかなり頻繁
にアクセスします。WebSphere Portal V7.0 のデフォルト・テーマは、要求ごとにポリシー
を使用してこのキャッシュを照会しますが、ポリシーをまったく使用しないテーマを作成
することも可能です。さらに、メールを開く際にキャッシュにアクセスします。このキャ
ッシュにエントリーを作成する際に、データベースからデータを読み取ります。このキャ
ッシュのエントリーのサイズはかなり小型です。
com.ibm.wps.policy.services.UserPolicyNodeCacheManager
デフォルトのサイズ: 2500、デフォルトの存続時間: 600、使用パターン: 通常
このキャッシュには、ユーザー識別名など、ポリシーとポリシー・ターゲットとの間の接
続が保存されます。テーマ・ポリシーはターゲットを使用しないので、このポリシーに基
づくキャッシュ・エントリーはありません。初期設定のメール・ポリシーはユーザーをタ
ーゲットとして使用します。したがって、CPP メール・ポートレットにアクセスするユー
ザーごとに少なくとも 1 つのエントリーが存在します。キャッシュされたエントリーのサ
イズは、ターゲット・オブジェクトのサイズによって変化します。識別名の場合、このキ
ャッシュのエントリーはかなり小型です。
172
WEBSPHERE PORTAL 7.0 TUNING GUIDE
コラボレーション・サービス
次のキャッシュはすべて DEPP ポートレットとこのポートレットの周りにある一部のサー
ビスによって使用されます。その範囲では、DEPP ポートレットがポータル・システムで利
用されない場合キャッシュは使用されません。これらのキャッシュは、バックエンド・サ
ービスで必要な証明書情報、これらのサーバーのサーバー情報、およびこれ以外に LDAP 検
索に必要なユーザー情報が保存されます。
173
WEBSPHERE PORTAL 7.0 TUNING GUIDE
com.lotus.cs.services.directory.ldap.BasicLDAPDirectoryService.server
デフォルトのサイズ: 50、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、メール・サーバー情報が保存されます。その範囲において、このキ
ャッシュのサイズは、その環境で使用されているメール・サーバーの数に合わせて決まり
ます。メール・サーバーにアクセスがあるたびに、このキャッシュにもアクセスがありま
す。キャッシュ・エントリーの作成には、1 つの LDAP 検索が必要です。このキャッシュ
のエントリーのサイズはかなり小型です。
com.lotus.cs.services.directory.ldap.BasicLDAPDirectoryService.user
デフォルトのサイズ: 2000、デフォルトの存続時間: 10780、使用パターン: 通常
このキャッシュには、LDAP から読み取られたユーザー固有情報が保存されます。このキャ
ッシュのサイズは、DEPP ポートレットで作業しているユーザーの数に合わせて決まります。
DEPP ポートレットのレンダリング中にユーザー情報が必要になるとキャッシュへのアク
セスが発生します。これは、ページのリロードのたびに複数回になる場合もあります。さ
らに、メール・サーバーにアクセスがあるたびに、このキャッシュにもアクセスがありま
す。キャッシュ・エントリーの作成はかなりコストの発生する処理で、複数の LDAP 検索
が含まれる可能性があります。このキャッシュのエントリーのサイズは中程度です。
com.lotus.cs.services.directory.wmm.WMMDirectoryService
デフォルトのサイズ: 4000、デフォルトの存続時間: 10980、使用パターン: 通常
このキャッシュには、LDAP および WMM から読み取られたユーザー固有情報が保存され
ます。このキャッシュ内のエントリーは、LDAP 内に保存されるデータで、他の WebSphere
Portal の部分で使用可能なものよりも完全なデータ セットです。このキャッシュのサイズ
は、DEPP ポートレットで作業しているユーザーの数に合わせて決まります。DEPP ポート
レットのレンダリング中にユーザー情報が必要になるとキャッシュへのアクセスが発生し
ます。これは、ページのリロードのたびに複数回になる場合もあります。さらに、メール・
サーバーにアクセスがあるたびに、このキャッシュにもアクセスがあります。キャッシュ・
エントリーの作成はかなりコストの発生する処理で、複数の LDAP 検索が含まれる可能性
があります。このキャッシュのエントリーのサイズは中程度です。
com.lotus.cs.services.UserEnvironment
デフォルトのサイズ: 2000、デフォルトの存続時間: 10880、使用パターン: 通常
174
WEBSPHERE PORTAL 7.0 TUNING GUIDE
このキャッシュには、ユーザー固有情報が保存されます。エントリーは、1 人のユーザー
の証明書情報を別の LDAP ディレクトリーにコンパイルしたことと、指定ユーザーのどの
データがどのディレクトリーにあるのかの詳細を表します。例えば、一般情報があるディ
レクトリーに保存され、メール・サーバーとファイルは別のディレクトリーに保存される
場合があります。このキャッシュのサイズは、DEPP ポートレットで作業しているユーザー
の数に合わせて決まります。DEPP ポートレットにアクセスがあるたびに、このキャッシュ
にもアクセスがあります。複数のリソースが照会される可能性があるため、キャッシュ・
エントリーの作成はかなりコストの発生する処理です。このキャッシュのエントリーのサ
イズは中程度です。
com.lotus.cs.services.domino.DominoService
デフォルトのサイズ: 2000、デフォルトの存続時間: 11080、使用パターン: 通常
このキャッシュには、ユーザー固有の Domino 情報が保存されます。認識機能に使用され
ます。このキャッシュのサイズは、対応する機能で作業しているユーザーの数に合わせて
決まります。ページのレンダリング中に認識機能が要求されるたびに、キャッシュにアク
セスされます。キャッシュ・エントリーの作成に要するコストは少なく、単純に新規 Domino
セッションの作成が含まれています。このキャッシュのエントリーのサイズは中程度です。
175
WEBSPHERE PORTAL 7.0 TUNING GUIDE
その他
このキャッシュのグループは、他のカテゴリーとは適合しません。
com.ibm.wps.pe.portletentity
デフォルトのサイズ: 10000、デフォルトの存続時間: 5800、使用パターン: 通常
このキャッシュには、ページ上のポートレットの構成 (ポートレット・インスタンス、共有
およびユーザーごと) が保存されます。このキャッシュのサイズは、ポータルに定義されて
いるページ数、ページ上のポートレット数、ユーザーによってパーソナライズされたポー
トレット・インスタンスの数に合わせて決まります。ポータル・ページのレンダリング中
に複数回キャッシュへのアクセスが発生します。その範囲では、ほとんどの関連ポートレ
ット・エントリーがキャッシュされることが重要です。このキャッシュにエントリーを作
成するには、1 回のデータベース検索が必要です。このキャッシュのエントリーのサイズは
かなり小型です。
例:500 ページあり、ページごとに平均して 3 つのポートレットのあるポータルで、ユーザ
ーによるポートレットのパーソナライズが許可されていない場合、すべての可能性のある
ポートレット・エンティティー・データを保存するために最適なキャッシュ・サイズは 1500
です。ポータルに連続してログインしたユーザーが 100 人いて、これらのユーザーが平均
して 50 のポートレットをパーソナライズした場合、すべてのデータをキャッシュするた
めに必要なキャッシュ・サイズは 6500 です。これらの数字により、キャッシュヘの最大
エントリー数が決まります。一般的にこのキャッシュに対してすべてのポートレット・エ
ンティティーがメモリーにある必要がありません。すべてのページを見るユーザーはほと
んどなく、パーソナライズされたすべてのデータをロードしなければならないわけではな
いからです。しかし、最も頻繁にアクセスされる、パーソナライズされていないポートレ
ットのエンティティーはキャッシュされる必要があります。
com.ibm.wps.services.cache.cachedstate.CachedStateServiceCache.cache
デフォルトのサイズ: 50000、デフォルトの存続時間: 7200、使用パターン: 一般的に通常
このキャッシュには、ポータル・コンテキスト内のセッション範囲のデータが保存され、
さまざまなポータル・コンポーネントによって使用されます。このキャッシュのサイズは、
システム内のアクティブ・セッションの数と、データ取得用にこのキャッシュを使用する
ポータル・コンポーネントの数に合わせて直線的に決まります。使用パターン、アクセス
時間、エントリー作成コスト、およびエントリー・メモリー・サイズは、このキャッシュ
176
WEBSPHERE PORTAL 7.0 TUNING GUIDE
を使用しているポータル・コンポーネントによって左右され、一般的に指定することはで
きません。
wp.xml.configitems
デフォルトのサイズ: 1000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、XML Access 構成項目が保存されます。XML Access 処理中にのみ使
用されます。エントリーは、XML Access 文書内にあるノード間の参照に似ています。特に、
通常はインポートまたはリリース・ビルダー・プロセスで使用されるような複雑な XML フ
ァイルで作業している場合、キャッシュ・サイズを増やすと便利でしょう。キャッシュは、
XML 処理が完了した後にクリアーされます。このキャッシュにエントリーをリロードする
には、1 回のデータベース照会が必要です。このキャッシュのエントリーのサイズは中程
度です。
177
WEBSPHERE PORTAL 7.0 TUNING GUIDE
PortletMenuCache
デフォルトのサイズ: 200、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、ポータル・メニューをグローバルと定義した (つまりすべてのユーザ
ーに対して同一である) すべてのポータルのポートレット・メニュー・ツリーが保存されて
います。このキャッシュを利用するポータルの機能は、WebSphere Portal Version V7.0 では
非推奨になりました。
RegistryService
デフォルトのサイズ: 32、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュは、管理作業のためにレジストリーの 1 つをリロードしなければならない
場合に、他のクラスター・メンバーに通知するためにポータルのクラスターで使用されま
す。これを無効にするか、shared=false に設定しないでください。
com.ibm.workplace.searchmenu.helper.SearchMenuCacheHelper
デフォルトのサイズ: 2500、デフォルトの存続時間: 3730、使用パターン: 通常
このキャッシュには、テーマの上部にある検索ボックスの左側の検索範囲メニューで実行
すべきさまざまな情報が保存されています。比較的小型のキャッシュ・エントリーがユー
ザーごとに 6 つあります。したがって、このキャッシュのサイズは、直接ユーザー数に合
わせて決まります。キャッシュからの無効化はありませんが、ログイン後にユーザーは、
キャッシュとユーザー・セッションのカップリングを通じて、常に最新のデータをキャッ
シュから取得できます。後続の、検索バーを作成するためのユーザー要求のたびに、キャ
ッシュへのアクセスが発生します。検索バーが使用されない場合、いずれにせよキャッシ
ュは使用されません。キャッシュの再作成に要するコストは比較的少ないのですが、必要
なデータを取得するために検索エンジン・バックエンドへのコールが必要です。
178
WEBSPHERE PORTAL 7.0 TUNING GUIDE
シナリオ例
このセクションでは、使用シナリオ例について、可能性のあるキャッシュ設定と推奨する
キャッシュ・サイズと共に説明します。使用している環境におけるキャッシュの開始点と
してこの説明が役に立つと思われます。
一般的なコメント
ほとんどのポータル・キャッシュは、次の 4 つのグループにまとめることができます。
1. エントリー数がアクティブなユーザー数に合わせて決まるキャッシュ。例えば、アクセ
ス 制 御 ユ ー ザ ー ・ コ ン テ キ ス ト ・ キ ャ ッ シ ュ
(com.ibm.wps.ac.
AccessControlUserContextCache) はこのカテゴリーに含められます。
2. エントリー数が特定の機能を使用するユーザー数に合わせて決まるキャッシュ。例えば、
キャッシュ com.lotus.cs.services. directory.ldap.BasicLDAPDirectoryService.user はこのカテ
ゴリーに含められます。
3. 訪 問 さ れ る ペ ー ジ 数 に 合 わ せ て 決 ま る キ ャ ッ シ ュ 。 リ ソ ー ス ・ キ ャ ッ シ ュ
(com.ibm.wps.model.content.impl.ResourceCache) は、このタイプの例です。
4. キャッシュ com.ibm.wps.model.factory. URLMappingCache.live 内に保存される、URL マッ
ピングなど他のいくつかのリソースの増加を基準として決まるキャッシュ。
ポータル・リソースを基準とするこれらのキャッシュには、システム内のポータル・リソ
ース数およびそれらのリソースのユーザー・アクセス頻度に基づいた、存続時間とサイズ
があります。他のキャッシュは、このセクションで説明しているような利用シナリオによ
って左右されます。
キャッシュされたコンテンツは時間の経過と共に変化するため、ほとんどのキャッシュに
はこれらに関連した存続時間があります。例えば、アクセス制御情報は、管理ポートレッ
ト内のユーザー管理、XML Access、または WebSphere Portal スクリプティング・インター
フェースを介して変更可能です。WebSphere Portal 内でキャッシュを使用するすべてのコ
ードは、対応する情報が変更または削除された場合に有効ではなくなったキャッシュ・エ
ントリーがキャッシュから削除されるような方法で実装されます。したがって存続時間は、
次の 3 つの理由から使用されます。
•
. 有効期限の切れたキャッシュ・エントリーを削除してメモリーの空き容量を増やすこ
とができます。
179
WEBSPHERE PORTAL 7.0 TUNING GUIDE
•
. 無効化イベントが正しく処理されたもののキャッシュには依然として間違ったデー
タが反映されているようなクラスター設定で、まれに競合状態が発生します。
•
. 外部システム内の更新は、外部アクセス制御システムのように、決して可視化されま
せん。
180
WEBSPHERE PORTAL 7.0 TUNING GUIDE
システムに管理がまったくないかほとんどなく、Java ヒープで使用可能な空きメモリー容
量がある場合、キャッシュ・データのリロードに対する追加の作業負荷を節約するために、
キャッシュの内容の存続時間を増やすことは安全です。
ここでは、特定のシナリオに対するいくつかの推奨事項について考察してみます。
ページ数が少なく、ユーザー数が少ない場合
このシナリオでは、ポータルのページ数とポータルにアクセスするユーザー数が限られて
います。例えば、システム内に 200 ページがあり、最大で数百ユーザーが同時に作業する
ような場合です。小規模のポータル本稼働システムの開発およびテストを行っているとき
にこのようなポータルがあると思われます。
このサイズと使用量のポータルの場合、一般的にキャッシュ値は良好です。したがって、
上記で示したデフォルト設定に対してわずかな変更のみが必要です。それでも、これらの
キャッシュ設定を大規模なユーザー・コミュニティー用の本稼働システムにそのまま変換
して使用しないように注意してください。
ページ数が少なく、ユーザー数が多い場合
このシナリオでは、ポータルで比較的少ないページ数のみが提供されています。全体とし
て数百ページですが、アクセス権は異なっているため、ユーザーはページのサブセットの
み閲覧可能です。しかしこのシナリオでは、システムへ同時にアクセスするユーザー数は
数千です。つまり、数千ユーザーにアクティブ・セッションがあることになります。
ページ上の情報を保存するキャッシュのプロパティーは、一般的にこのシナリオでは変更
する必要がありません。しかし、ユーザー依存情報を保存するすべてのキャッシュには問
題が発生する可能性があります。システム内に 2000 のアクティブ・ユーザーがいると想
定してみます。ユーザー単位のキャッシュ・サイズは 1000 エントリーのみですが、ほぼ
すべての時間上限で操作し、結果としてポータル・データベースからのデータの再計算ま
たはリロードが絶えず発生します。ユーザー依存のキャッシュのサイズは、現在のアクテ
ィブ・ユーザー数に対して十分なエントリー数がメモリー内の残せるようにする必要があ
ります。セッションがあり WebSphere Portal に対して要求を発行している「現在アクティ
ブなユーザー」の数を定義します。一方、セッションがあるものの、要求は発行しておら
ずログアウトするのを忘れているか、単純に画面から離れてセッションがタイムアウトし
181
WEBSPHERE PORTAL 7.0 TUNING GUIDE
たパッシブ・ユーザーもいます。
すべての同時ユーザーをキャッシュに組み込めるように、測定環境で次の 9 つのキャッシ
ュのサイズを増やします。
•
. com.ibm.wps.model.factory.ContentModelCache.live
•
. com.ibm.wps.ac.ExplicitEntitlements Cache.USER_GROUP
•
. com.ibm.wps.model.factory.NavigationSelectionModelCache.live
•
. com.ibm.wps.datastore.services.Identification. SerializedOidString.cache
•
. com.ibm.wps.puma.OID_User_Cache
•
. com.ibm.wps.puma.DN_User_Cache
182
WEBSPHERE PORTAL 7.0 TUNING GUIDE
•
. com.ibm.wps.puma.OID_DN_Cache
•
. com.ibm.wps.puma.DN_Group_Cache
•
. com.ibm.wps.puma.OID_Group_Cache
すべてのキャッシュの存続時間を少なくとも 1 時間まで増やしました。
長いセッション・タイムアウトのあるポータル
セッション・タイムアウトの値が高い場合、ポータルのセッションを持つものの、かなり
の期間そのサイトと対話してないユーザーが数多くいると思われます。これらのユーザー
はパッシブ・ユーザーと呼ばれ、特別なパフォーマンス上の問題を引き起こす可能性があ
ります。
この状況で、セッション数が多くなる可能性があります。しかし一般的にこれらのセッシ
ョンの多くは「パッシブ」です。昼食時などユーザーが離席したときに、通常はこれらの
ユーザーすべてに対してすべての情報をメモリー内に持つ必要はありません。ポータル・
キャッシュの適切なサイズを見つけるために、ユーザーの行動をよく把握しておく必要が
あります。一般的に、1 時間以上ポータルで作業してないユーザーは、このような長い休
憩の後の最初の要求時に応答時間が 2 ～ 3 秒程度になっても気にしませんが、比較的コ
ンスタントにポータルで作業しているユーザーは、データがキャッシュからクリアーされ
ていることを望みません。
このシナリオの場合、正確な推奨キャッシュ・サイズを示すことは困難です。値は、単純
にユーザー側のポータル使用シナリオに大幅に依存します。システムとユーザーをよく監
視して、最適な値を決める必要があります。
ページ数が多いあるポータル
このグループのポータルは、数千ページあり、大人数のユーザー・グループが利用可能な
ので、非常に頻繁にアクセスがある可能性があります。多くのカスタマイズされたページ
「
( 暗黙的な派生」とも言われます) のインストールはこのグループにはカウントしません。
このようなページにはプライベート・リソースがあり現在のユーザーのみにロードされる
からです。プライベート・データは共有ポータル・キャッシュには追加されません。
例えば、ポータルのページ数が合計で 5000 ページとします。その半分はすべてのユーザ
183
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ーが使用可能で、もう半分は複数のユーザー・グループに表示権限があり、残りのユーザ
ー・グループにこれらのページの管理権限があります。この場合、一般的にすべてのペー
ジとすべての対応情報を常にメモリー内に置きたいとは考えないはずです。しかし、頻繁
にアクセスするデータはすべてメモリーに置かれているようにしたいはずです。通常、す
べてのポータル・ページが同じような頻度でアクセスされるわけではありません。ページ・
ビューの統計がうまく作成されれば、それだけポータル・キャッシュのチューニングが簡
単になります。
シナリオに応じて頻繁にアクセスされるすべてのページをキャッシュできるように、測定
環境で次のキャッシュのサイズを増やします。
•
. com.ibm.wps.datastore.pageinstance.OIDCache
•
. com.ibm.wps.datastore.pageinstance.DerivationCache
184
WEBSPHERE PORTAL 7.0 TUNING GUIDE
•
. com.ibm.wps.model.factory.ContentModelCache
•
. com.ibm.wps.model.factory.NavigationSelectionModelCache
•
. com.ibm.wps.ac.PermissionCollectionCache
•
. com.ibm.wps.ac.ProtectedResourceCache
•
. com.ibm.wps.ac.ExplicitEntitlementsCache.USER_GROUP
•
. com.ibm.wps.datastore.services.Identification. SerializedOidString
すべてのキャッシュの存続時間を少なくとも 1 時間まで増やしました。
Web Content Management キャッシュ
前の章では、ここで取り上げている環境で Web Content Management (WCM) キャッシュに
使用できるように変更した具体的な値について説明しました。この章では、Web Content
Management キャッシュとこのキャッシュの一般的なパラメーターについて説明します。
WCM キャッシュ・インスタンス
WebSphere Portal V7.0 では、WCM は、WebSphere Application Server 管理コンソールの「リ
ソース(Resources)」→「キャッシュ・インスタンス(Cache instances)」→「オブジェクト・
キャッシュ・インスタンス (Object cache instances)」で管理します。
WCM 項目キャッシュ
services/cache/iwk/strategy .WCM 項目キャッシュ
デフォルトのサイズ: 2000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、内部 WCM 項目が保存されます。データベースから読み取られた
WCM 項目は、まずこのキャッシュを確認します。WCM 項目は、コンテンツ、ワークフロ
ー、ワークフロー・ステージ、ワークフロー・アクション、分類構造、カテゴリー、オー
サリング・テンプレート、プレゼンテーション・テンプレート、サイト、サイト領域、お
よびすべてのライブラリー・コンポーネントが対象です。キャッシュ・エントリーは、対
応する WCM 項目が更新または削除されるときに更新またはクリアーされます。
185
WEBSPHERE PORTAL 7.0 TUNING GUIDE
WCM サマリー
services/cache/iwk/objectsummary .WCM サマリー
デフォルトのサイズ: 2000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、WCM 項目のサマリーが保存されます。サマリーは、オーサリング・
ポートレット内のリストに表示されるのに使用されるか、イテレーターに使用される WCM
項目ドキュメント ID を計算するために WCM API で内部的に使用されます。このキャッシ
ュ・エントリーは、このサマリーに影響する WCM 項目が更新されるときにクリアーされ
ます。
WCM 基本キャッシュ
services/cache/iwk/module
デフォルトのサイズ: 2000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュは、ECM 基本キャッシュに使用されます。基本キャッシュの設定について
は、InfoCenter を参照してください。基本キャッシュには、応答全体が保存されます。キー
は、URL にのみ基づいているので、すべてのユーザーが同じ応答を見ます。
拡張およびリソース
services/cache/iwk/processing .拡張およびリソース
デフォルトのサイズ: 2000、デフォルトの存続時間: 1 か月（構成可能）
、使用パターン: 通
常
このキャッシュには、ファイルのバイナリ MIME と WCM 内のイメージ・リソースが保存
さ れ ま す 。 保 存 さ れ る リ ソ ー ス の 最 大 サ イ ズ は 、 プ ロ パ テ ィ ー
resourceserver.maxCacheObjectSize として WCMConfigService.properties ファイル内に KB
単位で設定されます。このサイズを超過するリソースはキャッシュされず、直接応答に流
れます。存続時間は同じファイルに resourceserver.cacheExpiryDate として設定されます。
キャッシュ・エントリーは、リソースが更新されるときにクリアーされます。
WCM 拡張キャッシュが有効な場合に、このキャッシュにページ・データも保存されます。
WCM 拡張キャッシュを有効にする方法については、InfoCenter を参照してください。処理
186
WEBSPHERE PORTAL 7.0 TUNING GUIDE
キャッシュには、次のタイプの拡張キャッシュが保存されます。
•
. サイト: 毎回「接続タグ」が処理される場合を除き、
「基本」キャッシュと類似してい
ます。
•
. ユーザー: 各ユーザーのキャッシュに項目のコピーを保存します。
•
. 保護: 同一グループに属するユーザーが同じキャッシュ済み項目にアクセスします。
•
. パーソナライズ: 同じパーソナライゼーション・カテゴリーおよびキーワードを選択
したユーザーで、同一グループに属するものは、同じキャッシュ済み項目にアクセス
します。
拡張キャッシュの「セッション」オプションは処理キャッシュには保存されず、
「セッショ
ン」キャッシュに保存されることに注意してください。
187
WEBSPHERE PORTAL 7.0 TUNING GUIDE
セッション・キャッシュ
services/cache/iwk/session – セッション
デフォルトのサイズ: 2000、デフォルトの存続時間: 無制限、使用パターン: 通常
セッション拡張キャッシュが有効なときに、このキャッシュにページ・データが保存され
ます。WCM 拡張キャッシュを有効にする方法については、InfoCenter を参照してください。
メニュー
services/cache/iwk/menu .メニュー
デフォルトのサイズ: 2000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、WCM メニュー・エントリーが保存されます。エントリーは、特定の
メニューに関連するコンテンツ ID で構成されています。エントリーは、セキュリティーの
適用なく取得され、キャッシュされます。ユーザーがそのメニューの結果を知る必要があ
るたびに、特定のセキュリティーがキャッシュされた結果に適用されます。(例えばユーザ
ー・プロファイルのカテゴリーに基づく) 現在のユーザーのコンテキストによって影響を受
ける動的メニューには、それぞれの異なるコンテキストの個別キャッシュ・エントリーが
保存されます。このキャッシュ・エントリーは、このメニューに影響する WCM 項目が更
新されるときにクリアーされます。
ナビゲーター
services/cache/iwk/nav .ナビゲーター
デフォルトのサイズ: 2000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、WCM ナビゲーターを構成する親子関係が保存されます。複雑なナビ
ゲーターには、複数の親子関係がある可能性があります (例えば、兄弟が含まれている場合
など)。ナビゲーター・エントリーは、親と子の ID で構成されます。このキャッシュは、
システム内での WCM 項目の更新時にクリアーされます。
絶対パス
services/cache/iwk/abspath .絶対パス
services/cache/iwk/abspathrev .絶対パス逆検索
188
WEBSPHERE PORTAL 7.0 TUNING GUIDE
デフォルトのサイズ: 5000、デフォルトの存続時間: 無制限、使用パターン: 通常
これらの 2 つのキャッシュには、WCM 項目 ID 関係 (1 つのキャッシュはパスと ID の関
係、もう 1 つは ID とパスの関係) への JCR パスが保存されます。このキャッシュ・エ
ントリーは、これに影響する WCM 項目が更新されるときにクリアーされます。一般的に、
これらの 2 つのキャッシュは同じサイズになるように構成されます。
189
WEBSPHERE PORTAL 7.0 TUNING GUIDE
消失項目
services/cache/iwk/missed .消失項目
デフォルトのサイズ: 5000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、存在しない JCR パスが保存されます。これは、他のロケールの項目
が存在するかどうかを判断するために、主に複数ロケール・ソリューションで使用されま
す。このキャッシュ・エントリーは、これに影響する WCM 項目が更新されるときにクリ
アーされます。
ライブラリー
services/cache/iwk/global - Library
デフォルトのサイズ: 2000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、ライブラリー ID、名前、およびライブラリー・オブジェクトへのパ
スの検索が含まれています。これは、ポータル起動時にキャッシュ・サイズまで事前に取
り込まれます。
ライブラリー親
services/cache/iwk/libparent .ライブラリー親
デフォルトのサイズ: 2000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、指定の親に対するすべての子ライブラリー ID のリストが保存されま
す。Quickr がチームスペース内のライブラリーをグループ化するために導入されました。
ドラフト・サマリー
Services/cache/iwk/draftSummary .ドラフト・サマリー
デフォルトのサイズ: 2000、デフォルトの存続時間: 無制限、使用パターン: 通常
このキャッシュには、ドラフト WCM 項目の ID に対するドラフト・サマリーの ID が保存
されます。
190
WEBSPHERE PORTAL 7.0 TUNING GUIDE
ユーザー・キャッシュ
ユーザー・キャッシュ
サイズは 2000 に固定されています。これはデフォルトで無効です。
このキャッシュは、最長未使用時間アルゴリズムを使用して操作します。クラスター内の
ノードにまたがって共有されず、dynacache を使用しません。LDAP 変更時には更新されま
せん。デフォルトで無効ですが、次の設定で有効にできます。
user.cache.enabled=true
これは WCMConfigService.properties に設定されています。MemberCacheManager というモ
ジュールを実行するか、サーバーを再起動する必要があります。モジュールを有効にする
には、WCMConfigService.properties に追加します。
191
WEBSPHERE PORTAL 7.0 TUNING GUIDE
connect.businesslogic.module.template.class=com.presence.connect.wmmcomms
connect.businesslogic.module.template.remoteaccess=true
connect.businesslogic.module.template.autoload=false
192
WEBSPHERE PORTAL 7.0 TUNING GUIDE
付録 A 参照
WebSphere Portal のインフォメーション・センター:
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp
WebSphere Application Server インフォメーション・センターのチューニング・セクション
は次の URL にあります。
http://www.ibm.com/software/webservers/appserv/was/library/
レッドブック「WebSphere Application Server V7.0 on the Solaris 10 Operation System」は次
の URL にあります。
http://www.redbooks.ibm.com/
WebSphere Portal のベンチマーク結果:
WPLC パフォーマンス・チームにご連絡ください。
DB2 のインフォメーション・センター:
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
Oracle のインフォメーション・センター:
http://www.oracle.com/technology/documentation/database10g.html
IBM pSeries サーバーの ROLTP 要素は、次の URL にあります。
http://www.ibm.com/servers/eserver/pseries/hardware/system_perf.html
詳細なパフォーマンス関連情報については、次のリソースを参照してください。
. WebSphere Application Server パフォーマンス情報:
http://www.ibm.com/software/webservers/appserv/was/performance.html
. 推奨する文書一覧:J2EE and WebSphere Application Server
http://www.ibm.com/developerworks/websphere/library/techarticles/0305_issw/recommendedr
eading.html
. WebSphere Application Server Development Best Practices for Performance and Scalability:
http://www.ibm.com/software/webservers/appserv/ws_bestpractices.pdf
193
WEBSPHERE PORTAL 7.0 TUNING GUIDE
. WebSphere Portal Performance Troubleshooting Guide
http://www-01.ibm.com/support/docview.wss?uid=swg27007059
194
WEBSPHERE PORTAL 7.0 TUNING GUIDE
付録 B クレジット
本書の作成に当たり、WebSphere Portal のパフォーマンス・チームの次のチーム・メンバ
ーに感謝します。
Mark Alkins、マネージャー
Lee Backstrom
Gaurav Bhagat
Jan-Paul Buchwald
Andrew Citron
Stephan Laertz
Kyung Chul Lee、ドキュメント・コーディネーター
Klaus Nossek
Denny Pichardo、テクニカル・リード
Martin Presler-Marshall
John Redmond
Terence Walker
Laura Yen
195
WEBSPHERE PORTAL 7.0 TUNING GUIDE
Copyright IBM Corporation 2010
IBM United States of America
Produced in the United States of America
All Rights Reserved
e-business logo、eServer logo、IBM、IBM logo、IBM Directory Server、DB2、Lotus、WebSphere
ｍ、POWER4、および POWER5 は International Business Machines Corporation の米国およ
びその他の国における商標です。
Lotus および Domino は Lotus Development Corporation または IBM Corporation の商標で
す。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。
Intel は、Intel Corporation または子会社の米国およびその他の国における商標または登録商
標です。
Linux は、Linus Torvalds の米国およびその他の国における商標です。
Solaris、Java、およびすべての Java 関連の商標とロゴは、Sun Microsystems, Inc. の米国お
よびその他の国における商標です。
Windows および Windows 2003 Enterprise Server は、Microsoft Corporation の米国およびそ
の他の国における商標です。
Oracle 10 およびすべての Oracle 関連の商標とロゴは、Oracle Corporation の米国およびそ
の他の国における商標です。
LoadRunner は、Mercury の米国およびその他の国における登録商標です。
他の会社名、製品名、およびサービス名などはそれぞれ各社の商標またはサービス・マー
クです。
196
WEBSPHERE PORTAL 7.0 TUNING GUIDE
IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提
供し、品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明
示もしくは黙示の保証責任を負わないものとします。国または地域によっては、法律の強
行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。
本書に記載する (ポートレットを含む) 製品の使用可能性に関する情報については正確性
を期していますが、IBM は、特定製品 (ポートレットを含む) が継続的に供給者より利用可
能になっていることを保証することはできません。
この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直
され、必要な変更は本書の次版に組み込まれます。IBM は予告なしに、随時、この文書に
記載されている製品またはプログラムに対して、改良または変更を行うことがあります。
本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載
しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの
Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サ
イトは、お客様の責任でご使用ください。
IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有して
いる場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾する
ことを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛
先にお送りください。
〒242-8502
神奈川県大和市下鶴間 1623 番 14 号
日本アイ・ビー・エム株式会社
法務・知的財産知的財産権ライセンス渉外
197
WEBSPHERE PORTAL 7.0 TUNING GUIDE