Sun ロゴ      前へ      目次      索引      次へ     

Sun ONE Calendar Server 6.0 管理者ガイド

付録 C
Calendar Server のパフォーマンスの調整

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

 


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

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

注 : Directory Server セットアップスクリプト (comm_dssetup.pl) を実行して Sun ONE Directory Server 5.x を設定する場合、icsCalendar 属性と icsCalendarOwned 属性のインデックス設定はこのスクリプトによって行われます。

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

http://docs.sun.com/db/coll/S1_ipDirectoryServer_51


LDAP ディレクトリサーバーのカレンダー検索機能の使用

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 秒でした。

Sun ONE 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.1

slapd-serverID は、slapd-serverID ディレクトリへの完全パスです。

nsSizeLimit パラメータと nsLookthroughLimit パラメータの設定

LDAP ディレクトリサーバー設定の nsSizeLimit パラメータと nsLookthroughLimit パラメータは、検索の正常な実行に必要な、十分なサイズに設定する必要があります

これらのパラメータに適切な値が設定されているかどうかを調べるには、次のコマンドを実行します。

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

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

LDAP サーバーがエラーを返す場合、nsSizeLimit または nsLookthroughLimit パラメータの値が十分でない可能性があります。次のガイドラインに従って、これらのパラメータを設定してください。


LDAP データキャッシュオプションの使用

LDAP データキャッシュオプションを使用することで、コミットされたデータの可用性に遅延がある場合でも、LDAP データをコミット直後に利用できるようになります。

たとえば、Calendar Server がスレーブ LDAP ディレクトリサーバーを通じてマスター LDAP ディレクトリにアクセスするマスター / スレーブ LDAP 構成をサイトに配備したために、コミットされた LDAP データの可用性に遅延生じるようになった場合でも、LDAP データキャッシュを使用することで、Calendar Server クライアントは常に正しい LDAP データを持つことができます。

詳細については、付録 D 「LDAP データキャッシュの使用」を参照してください。


CLD キャッシュオプションの使用

LDAP CLD プラグインを使用している場合は、ics.conf ファイルの次の設定パラメータを yes (各パラメータのデフォルト値) に設定します。

caldb.cld.cache.enable = "yes"

caldb.cld.cache.enable は CLD のキャッシュオプションを有効にします。このキャッシュがカレンダーユーザーの DWP ホストサーバー情報 (icsDWPHost LDAP 属性) を格納することで、LDAP ディレクトリサーバーに対する呼び出しを減らすことができます。

service.calendarsearch.ldap = "yes"

service.calendarsearch.ldap は、カレンダー検索に LDAP CLD プラグインまたはユーザー設定のプラグインを使用するように指定します。


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

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 を再起動して変更を適用します。


gse.belowthresholdtimeout パラメータの設定

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 を再起動します。



前へ      目次      索引      次へ     


Copyright 2003 Sun Microsystems, Inc. All rights reserved.