|
| |
| Sun Java System Calendar Server 管理ガイド | |
第 19 章
Calendar Server のパフォーマンスの調整Sun JavaTM System Calendar Server のパフォーマンスを向上させるには、次のオプション設定を検討します。
LDAP ディレクトリサーバーのインデックス設定Calendar Server が LDAP ディレクトリサーバーにアクセスするときのパフォーマンスを向上するには、LDAP 設定ファイルの次の属性にインデックスを追加します。
- icsCalendar 属性 : カレンダーユーザーまたはリソースのデフォルトカレンダーの検索に使用される。実在 (pres)、等価 (eq)、部分文字列 (sub) のいずれかのインデックスタイプを指定する。
- icsCalendarOwned : LDAP CLD プラグインが有効な場合に登録操作の検索に使用される。実在 (pres)、等価 (eq)、部分文字列 (sub) のいずれかのインデックスタイプを指定する。「DWP 環境でのカレンダー検索のパフォーマンス向上」も参照してください。
- mail および mailAlternateAddress : ユーザーの一次電子メールアドレスと代替アドレスを指定する。「必須の mail 属性」と「電子メールのエイリアス (mailalternateaddress 属性)」も参照してください。
注 Directory Server セットアップスクリプト (comm_dssetup.pl) を実行して Directory Server 5.x を設定する場合、icsCalendar 属性と icsCalendarOwned 属性のインデックス設定はこのスクリプトによって行われます。
ディレクトリサーバーインデックスの追加方法については、次の Web サイトで入手できる『Directory Server Configuration, Command, and File Reference』を参照してください。
http://docs.sun.com/db/coll/S1_ipDirectoryServer_51
DWP 環境でのカレンダー検索のパフォーマンス向上複数のバックエンドサーバー上にカレンダーデータベースがある場合、つまり、DWP 環境にいる場合、カレンダーの検索に非常に時間がかかる可能性があります。最初に LDAP エントリを探し、カレンダーが存在している DWP ホストで直接検索すると、時間を短縮できます。
最初に LDAP ディレクトリ、次にカレンダーデータベースを対象とするカレンダー検索を有効にするには、ics.conf ファイルで以下のようにパラメータが設定されていることを確認します。これはデフォルト値です。
service.calendarsearch.ldap = "yes"
次の処理を行うことで、LDAP ディレクトリのカレンダー検索のパフォーマンスを向上させることができます。
icsCalendarOwned 属性のインデックス設定
LDAP ディレクトリサーバーのカレンダー検索のパフォーマンスを向上させることができるかどうかを調べるには、次の LDAP コマンドを実行してみます。
ldapsearch -b "base"
"(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"base は、Calendar Server のユーザーとリソースのデータが格納されているディレクトリサーバーの LDAP ベース DN です。user は、エンドユーザーが「予約購読」->「カレンダーの検索」ダイアログで入力できる値です。
60,000 エントリを使ったテストでは、icsCalendarOwned のインデックスを設定しない場合、前述した検索に要した時間は 50 〜 55 秒でした。インデックスの設定後に検索に要した時間は、約 1 〜 2 秒でした。
Directory Server で icsCalendarOwned 属性にインデックスを設定するには、Solaris システムで次のコマンドを使用します。
server5/bin/slapd db2index -D slapd-serverID
-t icsCalendarOwned:eq,pres,sub:2.16.840.1.113730.3.3.2.11.1slapd-serverID は、slapd-serverID ディレクトリへの完全パスです。
nsSizeLimit パラメータと nsLookthroughLimit パラメータの設定
LDAP ディレクトリサーバー設定の nsSizeLimit パラメータと nsLookthroughLimit パラメータは、検索の正常な実行に必要な、十分なサイズに設定する必要があります。
これらのパラメータに適切な値が設定されているかどうかを調べるには、次のコマンドを実行します。
ldapsearch -b "base"
"(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"base は、Calendar Server のユーザーとリソースのデータが格納されているディレクトリサーバーの LDAP ベース DN です。user は、エンドユーザーが「予約購読」->「カレンダーの検索」ダイアログで入力できる値です。
LDAP サーバーがエラーを返す場合、nsSizeLimit または nsLookthroughLimit パラメータの値が十分でない可能性があります。次のガイドラインに従って、これらのパラメータを設定してください。
CLD キャッシュオプションの使用
LDAP 検索を最適化するには、CLD キャッシュオプションを次のように設定します ("yes" がデフォルト)。
caldb.cld.cache.enable = "yes"
「CLD キャッシュオプションの使用」も参照してください。
LDAP データキャッシュオプションの使用LDAP データキャッシュオプションを使用することで、LDAP ディレクトリサーバーがコミットされたデータの可用性の遅延を許容するように設定されている場合でも、LDAP データをコミット直後に利用できるようになります。
たとえば、Calendar Server がスレーブ LDAP ディレクトリサーバーを通じてマスター LDAP ディレクトリにアクセスするマスター / スレーブ LDAP 構成をサイトに配備したために、コミットされた LDAP データの可用性に遅延生じるようになった場合でも、LDAP データキャッシュを使用することで、Calendar Server クライアントは常に正しい LDAP データを持つことができます。
ここで説明する内容は次のとおりです。
LDAP データキャッシュの使用に関する注意
サイトで LDAP データキャッシュを利用するべきかどうか、次のガイドラインに基づいて検討してください。
- サイトの Calendar Server がマスター (ルート) LDAP ディレクトリサーバーに直接アクセスし、コミットされた LDAP データを遅延なしで利用できる場合は、LDAP データキャッシュを設定する必要はありません。local.ldap.cache.enable が no (デフォルト値) に設定されていることを確認してください。
- サイトに「マスター / スレーブの LDAP 構成」が導入され、Calendar Server がスレーブ LDAP ディレクトリサーバー経由でマスター LDAP ディレクトリにアクセスすることで、コミットされた LDAP データの可用性に遅延が生じている場合は、LDAP データキャッシュを設定し、エンドユーザーが最新のデータにアクセスできるようにします。
マスター / スレーブの LDAP 構成
マスター / スレーブの LDAP 構成には、マスター (ルート) ディレクトリサーバーと、1 つまたは複数のスレーブ (コンシューマまたはレプリカ) ディレクトリサーバーが含まれます。Calendar Server は直接、またはスレーブディレクトリサーバー経由でマスター LDAP ディレクトリサーバーにアクセスできます。
2 番目の構成では、コミットされた LDAP データをスレーブディレクトリサーバーで利用できるまでに遅延が発生するため、不正確な LDAP データが存在する問題があります。
たとえば、Calendar Server が LDAP データの変更をコミットしても、マスターディレクトリサーバーが各スレーブディレクトリサーバーを更新するまでの遅延により、ある程度の時間が経過するまで新しいデータは利用できません。それに続く Calendar Server の操作では、古い LDAP データが使用されるため、表示内容も古いままとなります。
スレーブディレクトリサーバーの更新遅延が短ければ (数秒程度)、クライアントは問題に気づかないかもしれません。しかし、遅延が数分から数時間におよぶ場合、遅延時間中はクライアントは不正確な LDAP データを表示することになります。
表 19-1 は、Calendar Server が スレーブ LDAP ディレクトリサーバー経由でマスター LDAP ディレクトリサーバーにアクセスする、マスター / スレーブの LDAP サーバー構成で遅延の影響を受ける LDAP 属性を示しています。
エンドユーザーが確実に最新の LDAP データにアクセスできるようにするには、次の「LDAP データキャッシュ」および「LDAP データキャッシュの設定パラメータ」に従って LDAP データキャッシュを設定します。
LDAP データキャッシュ
LDAP データキャッシュは、マスターディレクトリサーバーがスレーブディレクトリサーバーを更新していない場合でも、最新の LDAP データを Calendar Server のクライアントに提供することで、マスター / スレーブの LDAP 構成の問題を解決します。
LDAP データキャッシュを有効にすると、Calendar Server はコミットされた LDAP データをキャッシュデータベース (ldapcache.db ファイル) に書き込みます。デフォルトでは、LDAP キャッシュデータベースは cal_svr_base/var/opt/SUNWics5/csdb/ldap_cache ディレクトリに格納されますが、別の場所を指定することもできます。
クライアントが 1 人のユーザーの LDAP データを変更すると、Calendar Server は変更されたデータを LDAP キャッシュデータベースに書き込みます (スレーブディレクトリサーバーにも書き込まれる)。それに続くクライアント操作では、LDAP データはキャッシュデータベースから取得されます。このデータ取得は、1 人のユーザーに関する次の操作に適用されます。
つまり、LDAP データキャッシュデータベースには次の機能があります。
- 1 つのシステムでプロセス間のデータ整合性を維持する。データベースは、マルチプロセッサシステムのすべての Calendar Server プロセスで利用可能である
- ユーザーセッション間のデータ継続性を維持する。データベースは永続的で、再読み込みの必要がない。LDAP データキャッシュエントリの存続時間 (TTL) とデータベースクリーンアップの間隔は独自に設定できる。詳細については、「LDAP データキャッシュの設定パラメータ」を参照
制約
LDAP データキャッシュは次のような操作では機能しません。
- エントリのリストが事前にわかっている検索でのキャッシュの読み取り。たとえば、ミーティング参加者の検索などです。このような検索は、LDAP 遅延の対象となります。たとえば、新規作成したカレンダーは、LDAP 検索オプションが有効で、検索がカレンダー作成後の遅延期間内に実行された場合はカレンダー検索に表示されません。
- 複数のフロントエンドサーバー間でのキャッシュの読み取りと書き込み。それぞれのフロントエンドサーバーに専用のキャッシュがあり、別のキャッシュに含まれるデータの変更は認識されません。
- 常に同じサーバーにログインしないユーザーの取り扱い。このようなユーザーは、各サーバーのキャッシュに異なる LDAP データを生成することになります。
LDAP データキャッシュの設定パラメータ
表 19-2 は、ics.conf ファイル内の LDAP データキャッシュに関するパラメータを示しています。
警告
Calendar Server、または Calendar Server が稼動するサーバーを適切な方法で停止しなかった場合、データベースの破損によって以後の再起動時に問題が生じないように、ldap_cache ディレクトリ内のすべてのファイルを手動で削除します。
CLD キャッシュオプションの使用CLD プラグインを使用している場合は、ics.conf ファイルの次の設定パラメータを yes (各パラメータのデフォルト値) に設定します。
caldb.cld.cache.enable = "yes"
このパラメータは CLD キャッシュオプションを有効にします。このキャッシュがカレンダーユーザーの DWP ホストサーバー情報 (icsDWPHost LDAP 属性) を格納することで、LDAP ディレクトリサーバーに対する呼び出しを減らすことができます。
設定できるその他の CLD キャッシュオプションパラメータは次のとおりです。
これらのパラメータやその他の関連する ics.conf パラメータの詳細については、付録 E 「Calendar Server の設定パラメータ」を参照してください。
セッションデータベース用のメモリベースのファイルシステムの使用Solaris オペレーティングシステムでのパフォーマンスを向上するには、ics.conf ファイルの次のパラメータを設定して、セッションデータベース用のメモリベースのファイルシステム (tmpfs) を設定します。
local.instance.use.tmpfs を "true"
tmpfs ファイルシステムは、service.http.sessiondir.path パラメータと service.admin.sessiondir.path パラメータの値に基づいてオーバーレイされます。
詳細については、次のサイトで入手できる Solaris のマニュアルで tmpfs(7FS) および mount_tmpfs(1M) のマニュアルページを参照してください。
http://docs.sun.com/db/prod/solaris
複数 CPU 間でのロードバランスの使用サーバーが複数の CPU を利用できる場合、デフォルトでは Calendar Server は HTTP サービス (cshttpd プロセス) と分散データベースサービス (csdwpd プロセス) を複数の CPU に分散します。
各サービスを実際に実行するプロセッサの数は、service.http.numprocesses および service.dwp.numprocesses パラメータによって決定されます。デフォルトでは、これらのパラメータはインストール時にサーバーの CPU 数に設定されますが、この値を設定しなおすことができます。たとえば、サーバーに 8 つの CPU がある場合に、cshttpd および csdwpd プロセスを 4 つの CPU だけで実行するときは、これらのパラメータを次のように設定します。
service.http.numprocesses="4"
service.dwp.numprocesses="4"ロードバランスを無効にするには、値として no を指定した service.loadbalancing パラメータを ics.conf ファイルに追加します。次に、Calendar Server を再起動して変更を適用します。
タイムアウト値の使用Calendar Server のパフォーマンスは、さまざまな ics.conf パラメータのタイムアウト値を使用して調整できます。
次のタイプのタイムアウトが存在します。
ics.conf パラメータの編集については、「ics.conf 設定ファイルの編集」を参照してください。
csadmind のタイムアウト値
表 19-3 は、管理サービス (csadmind) が使用する、ics.conf ファイル内の Calendar Server タイムアウトパラメータを示しています。
エンドユーザーの HTTP タイムアウト値
表 19-4 は、エンドユーザーに適用される、ics.conf ファイル内の Calendar Server HTTP タイムアウトパラメータを示しています。
GSE キューのタイムアウト値
ics.conf ファイルの次のパラメータは、要求されたジョブを Calendar Server が GSE (グループスケジューリングエンジン) キューで走査するまでの時間を秒単位で指定します。
gse.belowthresholdtimeout = "3"
キューに含まれるジョブが許容最大しきい値より多い場合、最後のスレッドが常にキューをもう一度走査します。このため、この設定はジョブの数が最大しきい値より少ない場合にだけ適用されます。
デフォルトは 3 です。この値を大きくすると、サーバーがキューを走査する回数が減り、全体的なパフォーマンスを向上できます。ただし、予定のボリュームが増大したためにキューが大きくなりすぎた場合、キューの処理速度を上げるための時間が短くなる可能性があります。これによって全体のパフォーマンスは低下しますが、予定はすぐに更新されます。
再表示オプションの使用Refresh View オプションによって Calendar Express のエンドユーザーのパフォーマンスが向上します。このオプションを使用すると、Calendar Server データベースに更新情報を要求せずに、ブラウザキャッシュ内のカレンダーデータを使用して表示を更新することができます。
Refresh View オプションを有効にするには、ics.conf ファイルの次のパラメータに yes を指定します。
browser.cache.enable = "yes"
パラメータの設定を変更したら、Calendar Server を停止して再起動し、変更を適用します。
サイトに Refresh View オプションが設定されている場合、Calendar Express では「表示」タブのすべてのカレンダー表示に「Refresh View」を表示します。
ユーザーが「Refresh View」をクリックすると、Calendar Express はカレンダーデータベースに更新を要求する前に、ビューのカレンダーデータが変更されているかどうかを調べます。データが変更されていない場合は、Calendar Express はブラウザキャッシュの情報を使用して表示を更新します。カレンダーデータベースへの不要な要求を回避できるので、カレンダーに多数の予定や作業が設定されている場合は特に有用です。
予定または作業が変更されている場合、Calendar Express はカレンダーデータベースに更新内容を要求し、それを使用して表示を更新します。このため、ユーザーは Refresh View を使用することで、Calendar Express に常に最新のカレンダーデータを表示することができます。
Calendar Express ツールバーの再表示オプションの無効化ツールバー再表示オプションを使用すると、ユーザーが再表示のボタンをクリックしたときに、Calendar Express の表示が再表示 (再読み込み) されます。しかし、ツールバーの表示を更新するときに Calendar Server は XML と XSLT の変換を行うため、このオプションがパフォーマンス上の問題となることがあります。
ツールバーの再表示オプションを無効にするには、ics.conf ファイルの次のパラメータの値に no を指定します。
ui.toolbar.repainting.enable="no"
ui.toolbar.repainting.enable に no を指定すると、Calendar Express のどのビューで再表示を実行してもデフォルトビューに戻ります。
ui.toolbar.repainting.enable を no に設定することで、Calendar Express はツールバーの XML と XSLT の変換を行わなくなるため、パフォーマンスが向上します。
ブラウザのキャッシュオプション (browser.cache.enable パラメータ) が yes に設定されている場合、ツールバーの再表示オプションは使用されません。
クライアントブラウザの XSL レンダリングCalendar Server では、XSLT 処理をエンドユーザーのブラウザにダウンロードすることで、クライアント側のレンダリングを実行します。このため、Calendar Server が実行する必要のある処理は減少します。Calendar Server は、ブラウザが XSLT 処理のレンダリングに対応している場合にだけ XSLT 処理をダウンロードします。現在のリリースでは、この機能は Internet Explorer 6.0 以降だけに適用されます。
テストでは、クライアント側のレンダリングによってインタフェース (UI) のスケーラビリティが 4 〜 6 倍に向上する結果が示されています。これは、CPU のパフォーマンスを大幅に下げることなく、Calendar Server が 4 〜 6 倍の数の並行エンドユーザーをサポートできることを意味します。
クライアント側のレンダリングは、ics.conf ファイルの次のパラメータによって制御されます (現在は Internet Explorer 6.0 以降のみが対象)
render.xslonclient.enable="yes"
このパラメータはデフォルトで yes に設定されます。クライアント側のレンダリングをオフにするには、このパラメータに no を指定し、Calendar Server を再起動します。