第 21 章 Calendar Server のパフォーマンスの調整

Sun Java^TM System Calendar Server のパフォーマンスを向上させるには、次のオプション設定を検討します。

LDAP ディレクトリサーバーのインデックス設定

Calendar Server が LDAP ディレクトリサーバーにアクセスするときのパフォーマンスを向上するには、LDAP 設定ファイルの次の属性にインデックスを追加します。

icsCalendar 属性: カレンダーユーザーまたはリソースのデフォルトカレンダーの検索に使用されます。実在 (pres)、等価 (eq)、部分文字列 (sub) のいずれかのインデックスタイプを指定します。

icsCalendarOwned 属性: ユーザーが所有している他のカレンダーの検索に使用されます。実在 (pres)、等価 (eq)、部分文字列 (sub) のいずれかのインデックスタイプを指定します。「DWP 環境でのカレンダー検索のパフォーマンス向上」も参照してください。

mail 属性および mailAlternateAddress 属性: ユーザーの一次電子メールアドレスと代替アドレスを指定します。「必須の mail 属性を追加するには」と「電子メールのエイリアスを設定するには」も参照してください。



注	Directory Server セットアップスクリプト (comm_dssetup.pl) を実行して Directory Server 5.x を設定すると、スクリプトによってこれらやその他のインデックスが追加されます。第 2 章「ディレクトリ準備スクリプト (comm_dssetup.pl)」を参照してください。

ディレクトリサーバーインデックスの追加方法については、次の Web サイトで入手できる『Directory Server Configuration, Command, and File Reference』を参照してください。

DWP 環境でのカレンダー検索のパフォーマンス向上

DWP 環境にある場合、つまり、複数のバックエンドサーバーにカレンダーベースが分散している場合、カレンダーデータベース内のカレンダーの検索に非常に時間がかかる場合があります。最初に LDAP エントリを探し、カレンダーが存在している DWP ホストで直接検索すると、時間を短縮できます。

LDAP を対象とするカレンダー検索を有効にするには

最初に LDAP ディレクトリ、次にカレンダーデータベースを対象とするカレンダー検索を有効にするには、次の手順を実行します。

インデックスを作成して検索のパフォーマンスを向上させるには


注	公開カレンダーへの匿名アクセスを許可している場合は、LDAP を対象とするカレンダー検索を無効にすることもできます。Communications Express では、パラメータ値を "no" に設定することをお勧めします。

インデックスを作成することにより、カレンダー検索のパフォーマンスを向上させることができるかどうかを調べるには、次の LDAP コマンドを実行します。

ldapsearch -b "base" "(&(icscalendarowned=*user*)
(objectclass=icsCalendarUser))"

base は、Calendar Server のユーザーとリソースのデータが格納されているディレクトリサーバーの LDAP ベース DN です。user は、エンドユーザーが Calendar Express の「登録」-「カレンダーの検索」ダイアログで入力できる値です。

60,000 のエントリを使ったテストでは、icsCalendarOwned のインデックスを設定しない場合、前述した検索に要した時間は 50 ～ 55 秒でした。インデックスの設定後に検索に要した時間は、約 1 ～ 2 秒でした。

comm_dssetup.pl を実行して、適切な LDAP 属性に、または少なくとも icsCalendarOwned にインデックスを設定します。

comm_dssetup.pl は、この属性やその他の多くの属性にインデックスを設定して、さまざまな方法でパフォーマンスを向上させます。comm_dssetup.pl を実行していない場合、または実行したがインデックス設定を行わなかった場合、ユーティリティを再実行してインデックス設定を行うか、または Directory Server ツールを使用してインデックスを設定できます。

comm_dssetup.pl does indexing の使用方法については、「属性のインデックス」を参照してください。

http://docs.sun.com/coll/DirectoryServer_05q1

ワイルドカード検索の無効化によるカレンダー検索のパフォーマンスの向上

デフォルトでは、Calendar Server でのワイルドカード検索は無効になっています。つまり、グラフィカルユーザーインタフェース (GUI) を使用してカレンダーを検索するとき、または、カスタムインタフェースで search_calprops.wcap を実行するときは、WCAP コマンドを使用して渡される検索文字列との完全一致を検索します。

ics.conf ファイルで次の行のコメントを外して (行頭の感嘆符 (!) を削除して) ワイルドカード検索を有効にしている場合は、パフォーマンスにマイナスの影響を与える可能性があります。

!service.calendarsearch.ldap.primaryownersearchfilter = "(&(|(uid=*%s*)(cn=*%s*))(objectclass=icsCalendarUser))"

パフォーマンスに与えるワイルドカードの影響を調べるには、行の先頭に感嘆符 (!) を挿入して行をもう一度コメントアウトします。

CLD プラグインのパフォーマンスの向上

カレンダーデータベースからカレンダーにアクセスする前に、ユーザーのカレンダーをどのバックエンドマシンに格納するか決める必要があります。適切なバックエンドマシンを見つけるため、システムではユーザーエントリの LDAP ディレクトリを検索し、icsDWPHost 属性を取り出します。この検索は非常に時間がかかり、カレンダーデータにアクセスするたびに実行する必要があります。すべてのユーザーセッションでは、データベースのアクセスが多数発生し、LDAP の検索も多くなります。時間を節約してパフォーマンスを向上させるには、次のように ics.conf ファイルを編集して LDAP データキャッシュを有効にします。

LDAP データキャッシュは、ユーザー ID およびそれに関連する icsDWPHost 属性を格納します。LDAP でユーザーのエントリを検索する前に、システムはキャッシュにユーザー ID がないかどうかチェックします。キャッシュにユーザー ID があれば、そこに格納されている icsDWPHost 属性からバックエンドのホスト名を取り出します。キャッシュにユーザー ID がない場合、システムは LDAP 検索を実行して、ユーザー ID と属性をキャッシュにコピーします。この後は、キャッシュでユーザー ID が見つかるため、ユーザーのカレンダーデータへのアクセスが速くなります。

LDAP データキャッシュのパフォーマンスの向上

デフォルトでは、LDAP データキャッシュが有効になっています。ics.conf パラメータを使用してキャッシュを調整するには、表 21-1 にある 1 つ以上のパラメータを調整します。

表 21-1 LDAP データキャッシュのカスタマイズに使用される ics.conf パラメータ
パラメータ	説明と値
local.ldap.cache.checkpointinterval	チェックポイント間でチェックポイントスレッドがスリープするまでの秒数。デフォルトは "60" です。高アクティビティの LDAP では、キャッシュをできるだけ最新のものにしておくため、間隔を短くすることをお勧めします。同時に、キャッシュを更新が頻繁になるほど、システムのオーバーヘッドが高くなることにも留意してください。
local.ldap.cache.circularlogging	処理が完了した後に LDAP データキャッシュのデータベースログファイルを削除するかどうかを指定します。デフォルトは "yes" です。古いログファイルを削除するカスタムのクリーンアップルーチンがある場合を除いて、このパラメータは変更しないでください。
local.ldap.cache.logfilesizemb	チェックポイントファイルの最大サイズを M バイト単位で指定します。デフォルトは "10"M バイトです。高アクティビティの LDAP の場合、チェックポイント間隔が終わる前にこのファイルがいっぱいになる可能性があります。経験に基づいて、できるだけログの実サイズに近い値を設定します。
local.ldap.cache.maxthreads	LDAP データキャッシュデータベースの最大スレッド数を指定します。デフォルトは "1000" です。高アクティビティの LDAP では、スレッド数を増やすことをお勧めします。そうすることにより CPU の使用率が高くなります。LDAP アクティビティが最小の場合にのみ、スレッド数を減らします。
local.ldap.cache.mempoolsizemb	共有メモリのサイズを M バイト単位で指定します。デフォルトは "4"M バイトです。
local.ldap.cache.entryttl	LDAP データキャッシュエントリの存続時間 (TTL) を秒単位で指定します。デフォルトは "3600" 秒 (1 時間) です。キャッシュがあまりにも早くいっぱいになる場合は (高アクティビティ)、TTL 時間を減らします。ただし、これにより全体の LDAP データベースのアクセス数が増加し、全体的にシステムを低下させる可能性があります。
local.ldap.cache.cleanup.interval	キャッシュデータベースのクリーンアップの間隔を秒単位で指定します。デフォルトは "1800" 秒 (30 分) です。システムにより有効期限が切れたエントリが削除されます。時間間隔は、エントリの TTL 時間と同一である必要はありません。ただし、同期させるとより効率的になります。
local.ldap.cache.stat.enable	LDAP データキャッシュへのアクセスをログに記録し、ログファイルに統計情報を出力するかどうかを指定します。デフォルトは "no" です。パフォーマンス向上のために、このパラメータはデバッグモードでのみ使用してください。
local.ldap.cache.stat.interval	統計情報レポートをログファイルに書き込む間隔を秒単位で指定します。デフォルトは "1800" 秒 (30 分) です。これは、local.ldap.cache.stat.enable が有効になっている場合にのみアクティブになります。間隔を短くすると、問題を特定するのに役立ちます。間隔を長くすると、システムロードが減少します。


注	Communications Express では、データキャッシュを無効にすることをお勧めします。

LDAP SDK キャッシュの調整

項目をキャッシュしておく時間、およびキャッシュのサイズを制御するいくつかのパラメータがあります。

キャッシュを調整するには、表 21-2 に示すパラメータを 1 つ以上編集します。

表 21-2 LDAP SDK キャッシュを設定するための ics.conf パラメータ
パラメータ	説明とデフォルト値
service.ldapmemcachettl	service.ldapmemcache に "yes" を指定した場合、このパラメータは項目をキャッシュしておける最大秒数の設定に使用されます。0 を指定した場合、項目をキャッシュしておける時間に制限が適用されなくなります。デフォルトは "30" です。
service.ldapmemcachesize	service.ldapmemcache に "yes" を指定した場合、このパラメータを使用して、キャッシュに使用できるメモリの最大容量をバイト単位で設定します。"0" を指定した場合、キャッシュ容量の制限は適用されなくなります。デフォルトは "131072" です。

自動バックアップの調整

ディスクに保存するバックアップ数と必要性とのバランスを取って、使用可能なディスク容量を越えないようにする必要があります。アーカイブとホットバックアップに必要なディスク容量を管理するために、さまざまな ics.conf パラメータの設定を変更できます。これらのパラメータにより、一度に保存するバックアップのコピー数、および古いコピーのクリーンアップを行うディスク容量のしきい値が決定されます。

アーカイブ、およびホットバックアップのそれぞれバックアップタイプ用に調整できる次の 3 種類のパラメータがあります。

Calendar Server では、ディスク容量のしきい値を超えずに可能な最大日数の間、バックアップを保持します。そのため、現在のバックアップでディスク使用率がしきい値を超える場合、システムは古いバックアップコピーを破棄し、ディスク容量の使用率がしきい値より低くなるかどうかを確認します。システムは、別のバックアップコピーを削除することにより、ディスク上のバックアップ数が最小バックアップコピー数を下回るか、ディスク容量の使用率がしきい値を下回るまで、古いバックアップコピーを破棄し続けます。

その結果、しきい値のパラメータによりディスク容量のバックアップ使用を管理できます。また反対に、許容されるディスク容量やコピーを調整することにより、ディスクで保持するバックアップ量を管理できます。

表 21-3 は、ディスク容量とディスクに保持されるバックアップ数を制御する ics.conf パラメータをリスト表示します。

表 21-3 ディスク上に保持するバックアップ数の設定に使用される ics.conf パラメータ
ics.conf パラメータ	デフォルトの設定	説明
caldb.berkeleydb.hotbackup.mindays	3	ディスク上に保持するホットバックアップの最小日数です。
caldb.berkeleydb.hotbackup.maxdays	6	ディスク上に保持するホットバックアップの最大小日数です。
caldb.berkeleydb.hotbackup.threshold	70	ホットバックアップに使用されるディスク容量の割合 (パーセント) です。しきい値を超えた古いコピーの廃棄をトリガーします。
caldb.berkeleydb.archive.mindays	3	ディスク上に保持するアーカイブバックアップの最小日数です。
caldb.berkeleydb.archive.maxdays	6	ディスク上に保持するアーカイブバックアップの最大日数です。
caldb.berkeleydb.archive.threshold	70	アーカイブバックアップに使用されるディスク容量の割合 (パーセント) です。しきい値を超えた古いコピーの廃棄をトリガーします。

セッションデータベース用のメモリベースのファイルシステムの使用

パフォーマンスを向上するには、ics.conf ファイルの次のパラメータを設定して、セッションデータベース用のメモリベースのファイルシステム (tmpfs) を設定します。

tmpfs ファイルシステムは、service.http.sessiondir.path パラメータと service.admin.sessiondir.path パラメータの値に基づいてオーバーレイされます。

詳細については、次のサイトで入手できる Solaris のマニュアルで tmpfs(7FS) および mount_tmpfs(1M) のマニュアルページを参照してください。

複数 CPU 間でのロードバランスの使用

サーバーが複数の CPU を利用できる場合、デフォルトでは、Calendar Server は HTTP サービス (cshttpd プロセス) と分散データベースサービス (csdwpd プロセス) を複数の CPU に分散します。

各サービスを実際に実行するプロセッサの数は、service.http.numprocesses および service.dwp.numprocesses パラメータによって決定されます。デフォルトでは、これらのパラメータはインストール時にサーバーの CPU 数に設定されますが、この値を設定し直すことができます。たとえば、サーバーに 8 つの CPU がある場合に、cshttpd および csdwpd プロセスを 4 つの CPU だけで実行するときは、これらのパラメータを次のように設定します。

ロードバランスを無効にするには、値として "no" を指定した service.loadbalancing パラメータを ics.conf ファイルに追加します。次に、Calendar Server を再起動して変更を適用します。

タイムアウト値の使用

Calendar Server のパフォーマンスは、さまざまな ics.conf パラメータのタイムアウト値を使用して調整できます。

csadmind のタイムアウト値

表 21-4 は、管理サービス (csadmind) が使用する、ics.conf ファイル内の Calendar Server タイムアウトパラメータを示しています。

表 21-4 管理サービス (csadmind) の HTTP タイムアウト値
パラメータ	説明
service.admin.idletimeout	csadmind サービスがアイドル状態の HTTP 接続をタイムアウトにするまでの秒数を指定します。デフォルトは 120 秒 (2 分) です。
service.admin.resourcetimeout	csadmind サービスがリソースカレンダーの HTTP セッションをタイムアウトにするまでの秒数を指定します。デフォルトは 900 秒 (15 分) です。
service.admin.sessiontimeout	csadmind サービスが HTTP セッションをタイムアウトにするまでの秒数を指定します。デフォルトは 1800 秒 (30 分) です。

エンドユーザーの HTTP タイムアウト値

表 21-5 は、エンドユーザーに適用される、ics.conf ファイル内の Calendar Server HTTP タイムアウトパラメータを示しています。

表 21-5 ics.conf に設定され、エンドユーザーに適用される HTTP タイムアウト値 (cshttpd サービス)
パラメータ	説明
service.http.idletimeout	cshttpd サービスがアイドル状態の HTTP 接続をタイムアウトにするまでの秒数を指定します。デフォルトは 120 秒 (2 分) です。
service.http.resourcetimeout	cshttpd サービスがリソースカレンダーの HTTP セッションをタイムアウトにするまでの秒数を指定します。デフォルトは 900 秒 (15 分) です。
service.http.sessiontimeout	cshttpd サービスが HTTP セッションをタイムアウトにするまでの秒数を指定します。デフォルトは 1800 秒 (30 分) です。

GSE キューのタイムアウト値

ics.conf ファイルの次のパラメータは、要求されたジョブを Calendar Server が GSE (グループスケジューリングエンジン) キューで走査するまでの時間を秒単位で指定します。

キューに含まれるジョブが許容最大しきい値より多い場合、最後のスレッドが常にキューをもう一度走査します。このため、この設定はジョブの数が最大しきい値より少ない場合にだけ適用されます。

デフォルトは "3" です。この値を大きくすると、サーバーがキューを走査する回数が減り、全体的なパフォーマンスを向上できます。ただし、予定のボリュームが増大したためにキューが大きくなりすぎた場合、キューの処理速度を上げるための時間が短くなる可能性があります。これによって全体のパフォーマンスは低下しますが、予定はすぐに更新されます。

Calendar Express ユーザーインタフェースの調整

ここでは、次の方法で Calendar Express を調整する方法について説明します。

再表示オプションの使用

再表示オプションによって Calendar Express のエンドユーザーのパフォーマンスが向上します。このオプションを使用すると、Calendar Server データベースに更新情報を要求せずに、ブラウザキャッシュ内のカレンダーデータを使用して表示を更新することができます。

再表示オプションを有効にするには、ics.conf ファイルの次のパラメータに "yes" を指定します。

パラメータの設定を変更したら、Calendar Server を停止して再起動し、変更を適用します。

サイトに再表示オプションが設定されている場合、Calendar Express では「表示」タブのすべてのカレンダー表示に「再表示」を表示します。

ユーザーが「再表示」をクリックすると、Calendar Express はカレンダーデータベースに更新を要求する前に、ビューのカレンダーデータが変更されているかどうかを調べます。データが変更されていない場合は、Calendar Express はブラウザキャッシュの情報を使用して表示を更新します。カレンダーデータベースへの不要な要求を回避できるので、カレンダーに多数の予定や作業が設定されている場合は特に有用です。

予定または作業が変更されている場合、Calendar Express はカレンダーデータベースに更新内容を要求し、それを使用して表示を更新します。このため、ユーザーは再表示を使用することで、Calendar Express に常に最新のカレンダーデータを表示することができます。

ツールバーの再表示オプションの無効化

ツールバー再表示オプションを使用すると、ユーザーが再表示のボタンをクリックしたときに、Calendar Express の表示が再表示 (再読み込み) されます。しかし、ツールバーの表示を更新するときに Calendar Server は XML と XSLT の変換を行うため、このオプションがパフォーマンス上の問題となることがあります。

ツールバーの再表示オプションを無効にするには、ics.conf ファイルの次のパラメータの値に "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 以降のみが対象)。

このパラメータはデフォルトで "yes" に設定されます。クライアント側のレンダリングをオフにするには、このパラメータに "no" を指定し、Calendar Server を再起動します。

前へ目次索引次へ
Sun Java System Calendar Server 6 2005Q1 管理ガイド