ソフトウェアの境界を計画する (Project Server)
更新日: 2009年5月
トピックの最終更新日: 2015-03-09
この記事の内容 :
テスト環境
テスト結果
許容範囲のパフォーマンスに関するガイドライン
ここでは、Microsoft Office Project Server 2007 のテスト済みパフォーマンスと容量の制限を理解するために役立つ情報、およびテスト環境とテスト結果についての情報を提供し、許容範囲のパフォーマンスに関するガイドラインを示します。この記事の情報を使用して、計画した展開が許容範囲のパフォーマンスと容量の制限内に収まるかどうかを確認してください。
ここで提供するテスト結果とガイドラインは、Office Project Server 2007 の単一インストールに適用されます。インストールにサーバー コンピュータを追加しても、「許容範囲のパフォーマンスに関するガイドライン」の表に記載されているサイト オブジェクトの容量制限は増大しません。一方、サーバー コンピュータを追加すると、サーバー ファームのスループットは増大します。これは、多数のオブジェクトで許容範囲のパフォーマンスを達成するために必要な場合があります。場合によっては、ソリューション内の多数のオブジェクトに対する要求により、複数のサーバー ファームの使用が必要になります。
この記事では、ガイドラインはパフォーマンスによって決定されます。つまり、このガイドラインを超過することはできますが、規模の拡大によってパフォーマンスが低下する場合があります。
特定の環境でパフォーマンスに影響する多くの要因があり、これらの各要素が別の領域のパフォーマンスに影響する可能性があることに注意してください。この記事のテスト結果と推奨事項の中には、それぞれの環境に存在しない機能やユーザー操作に関連しているため、自分のソリューションには適用されないものがある可能性があります。テストによってのみ、独自の環境に関連する正確なデータが得られます。
Office Project Server 2007 は Windows SharePoint Services 3.0 を基にしているので、Windows SharePoint Services 3.0 のパフォーマンスと容量に影響する要因のほとんどは Office Project Server 2007 にも影響します。Windows SharePoint Services 3.0 の容量とパフォーマンスの計画の詳細については、「パフォーマンスおよび容量を計画する (Windows SharePoint Services)」を参照してください。
テスト環境
テスト結果の詳細を提供するため、Web サーバーとアプリケーション サーバー ロールを実行する 1 台のサーバー コンピュータ、1 ～ 2 台のクライアント コンピュータ、および Microsoft SQL Server 2000 データベース ソフトウェアを実行する単一データベース サーバー コンピュータを含む、いくつかのファーム構成がテストに使用されました。一部のテストは、別のアプリケーション サーバー コンピュータで実行されました。また、専用のドメイン コントローラ コンピュータがテスト ラボで使用されました。すべてのサーバー コンピュータは 32 ビットでした。
次の表は、テスト環境で各ロールを実行するコンピュータの仕様の一覧です。
| コンピュータのロール | 仕様 |
|---|---|
Web サーバーとアプリケーション サーバー |
4 AMD Opteron 2.2 ギガヘルツ (GHz) プロセッサ、2 ギガバイト (GB) RAM |
アプリケーション サーバー |
4 AMD Opteron 2.2 GHz プロセッサ、2 GB RAM |
データベース サーバー |
4 Intel Xeon 1.5 GHz プロセッサ、4 GB RAM |
クライアント |
1 Pentium D 3 GHz プロセッサ、2 GB RAM |
ドメイン コントローラ |
2 Pentium III 1 GHz プロセッサ、512 MB RAM
|
ファーム コンピュータ間では、100 メガビットのイーサネット ネットワークが使用されました。
テスト結果
次のチャート、グラフ、表は、テスト環境で特定のサーバー構成、ユーザー操作、および負荷条件をどのように実行したかを示しています。提供される結果は、すべての類似した Office Project Server 2007 環境に適用されます。
[!メモ] 今後、追加の構成をテストする予定です。テスト結果は、使用可能になった時点で公開されます。
さまざまな操作に対するパフォーマンスの判断基準は、プロジェクト ファイルの大きさ、特定のプロジェクトに存在する基準計画の数、ファームのスループットなどの要因によって異なります。たとえば、小さなプロジェクト ファイル (1 MB 未満) は保存に 1 秒かからない場合もありますが、50 MB のプロジェクト ファイルは、ファームの構成やネットワーク遅延によっては保存に 1 分以上かかることがあります。
プロジェクトのサイズに関するテスト標準
次の表は、テストで使用した 3 種類のプロジェクト ファイルのサイズです。
| サイズ | ファイルのサイズ (MB) | タスクの数 | リソースの数 | 割り当ての数 |
|---|---|---|---|---|
小 |
0.896 |
10 |
10 |
10 |
中 |
2.03 |
1,420 |
94 |
実際のリソースでの割り当ては 1,486、未割り当ては 380 |
大 |
8.139 |
10,422 |
2 |
実際のリソースでの割り当ては 5、未割り当ては 7,693 |
Active Directory の同期
このテストは、リソース数の増加によって、Active Directory ディレクトリ サービスの同期のパフォーマンスがどれだけ低下するかを測定するために実施されました。
Windows SharePoint Services 3.0 は、Office Project Server 2007 の基本セキュリティとユーザー管理アーキテクチャを提供しています。Office Project Server 2007 のリソースとしてドメイン ユーザーを管理するには、ドメインの Active Directory をファーム内のいずれかのファームの Windows SharePoint Services 3.0 と同期する必要があります。
Active Directory の同期は、インポートされるリソースの数に比例して複雑にはなりません。複雑さは大ざっぱに言うと二次的であり、Windows SharePoint Services 3.0 と Active Directory 間の同期はこれを実証しています。テスト結果に基づき、20,000 人規模の組織に対する Windows SharePoint Services 3.0 の同期には、テスト ハードウェアで約 28 時間かかると推定できます。40,000 人規模の組織に対する Windows SharePoint Services 3.0 の同期は約 109 時間 (4.6 日) で完了します。これらの推定は、このテストで使用したハードウェアとネットワークの仕様に基づくことに注意してください。
一般に、リソース プールのサイズを倍にすると、特定のファーム構成とネットワーク帯域幅で Active Directory の同期に必要な時間は約 4 倍になります。ハードウェアに関係なく、非常に大規模な組織では、最初の Active Directory の同期ジョブの実行には 1 日以上かかる可能性があります。
次のグラフは、リソースの数が増えたときに Active Directory の同期を完了するために必要な時間を示しています。
.gif "Active Directory の同期のグラフ")
Active Directory と Office Project Server 2007 の同期の詳細については、「Project Server 2007 の Active Directory 同期の管理」を参照してください。
パフォーマンスへの基準計画の影響
Office Project Server 2007 では、特定のプロジェクト内に全部で 11 の基準計画を保存できます。プロジェクトの基準計画の数が増えると、パフォーマンスにいくつかの点で影響します。テストは、小規模、中規模、および大規模なプロジェクトの基準計画数の増加による、保存の影響を確認するために実施されました。
概して、このテストのファイルのサイズと仮想メモリの増加は、プロジェクト内に保存された基準計画の数と比例しているように見えます。基準計画を保存するために必要な時間は、プロジェクトのサイズによって長くなります。ファイル I/O 操作に必要な時間は、小規模および中規模プロジェクトでは基準計画の最大数まで増えませんでした。大規模プロジェクトでは、8 番目の基準計画を追加した後、ファイル I/O 操作に必要な時間が大幅に増えました。
.gif "Project Server 2007 の入出力チャート")
プロジェクトの深さと広さに関する制限
テストは、マスタ プロジェクトにサブプロジェクトを挿入したときのパフォーマンスへの影響を確認するために実施されました。2 種類のテストが実行されました。
深さに関するテスト (再帰)
広さに関するテスト (非再帰)
深さに関するテスト
深さに関するテストでは、再帰的にサブプロジェクトを挿入しました。たとえば、Proj01 を Proj02 に挿入しました。このチェーンを、次に Proj03 に挿入しました。このチェーンを Proj04 に挿入し、以下同様に繰り返しました。チェーン内の各プロジェクトはまったく同じもので、テストの目的は、各プロジェクト (小、中、大) を再帰的に挿入できる回数、およびさまざまなパフォーマンスの判断基準の対応を確認するためのものでした。
再帰的挿入のテストでは、事実上すべての重要なパラメータは直線的に増減しました。深さを制限する要因はメモリ使用量です。たとえば、16 レベルでは、約 10,000 タスクを含む大規模プロジェクトは 32 ビット仮想メモリの上限に近づきました。ただし、この例でも、保存操作は非常にすばやく実行されました。他の操作、たとえば、マスタ プロジェクトの開閉、新しい層の挿入、強制的な再計算などは、かなり時間がかかりました。64 ビットのサーバー プラットフォームでは、挿入できるプロジェクトの数は大幅に増えますが、深さがそれほど必要なプロジェクトは一般的ではありません。
次のグラフは、再帰的に挿入するプロジェクトの数を増やしたときに、ファイル I/O 操作を完了するために必要な時間がどれだけ長くなるかを示しています。かなり少数の再帰後に中規模プロジェクトのパフォーマンスに大幅な低下が見られたため、大規模プロジェクトについては示されていません。
.gif "Project Server ソフトウェア境界のグラフ")
広さに関するテスト
広さに関するテストでは、同じレベルで (つまり、再帰的にではなく) 1 つのマスタ プロジェクトにサブプロジェクトを挿入しました。
すべての主要パラメータは、プロジェクトの広さと比例して増減しました。中規模で非再帰的なファイルを約 35 個挿入した後は、メモリ使用量がボトルネックになります。また、保存操作やオープン操作を完了するために必要な時間は、20 プロジェクトの広さで約 400 秒です。再帰的な挿入と同様に、64 ビット プラットフォームの仕様によって、挿入できるプロジェクトの数は大幅に増えますが、それほどの広さが必要なプロジェクトは一般的ではありません。
次のグラフは、中規模サイズのプロジェクトで、非再帰的に挿入するプロジェクトの数を増やしたときに、ファイル I/O 操作を完了するために必要な時間がどれだけ長くなるかを示しています。
.gif "I/O 操作時間とプロジェクトのグラフ")
プロジェクト サーバーのパフォーマンスとネットワーク遅延
Office Project Server 2007 は、ネットワーク遅延の高い環境で適切に動作します。Office Project Server 2007 で行われた設計変更によって、一般的な 1 人のユーザーのファイル I/O シナリオでは、特にネットワーク遅延の高いワイド エリア ネットワーク (WAN) 環境において大きな利点があります。Project Server 2003 では、ネットワーク遅延の高い (50 ミリ秒) WAN 経由で大きなファイルを開くと 45 分もかかることがありましたが、Office Project Server 2007 でテストした同じ操作に必要な時間は 1 分未満でした。Office Project Professional 2007 のチーム ビルダは、WAN 環境でも同様のパフォーマンスの向上を示します。遅延の低いネットワーク接続を使用する利点は明らかですが、WAN 経由の Office Project Server 2007 のパフォーマンスは以前のバージョンのパフォーマンスと比べて大幅に向上しています。
Office Project Server 2007 の初期起動時のパフォーマンスは Project Server 2003 より劣りますが、その後の起動のパフォーマンスは大幅に向上し、前のバージョンより優れています。
許容範囲のパフォーマンスに関するガイドライン
容量には、スケーラビリティの影響が直接及びます。ここでは、Microsoft Office Enterprise Project Management (EPM) Solution を構成するオブジェクトについて説明し、各種類のオブジェクトに対する許容範囲のパフォーマンスに関するガイドラインを示します。
1 つ以上のオブジェクトに対し、ンソリューション計画が推奨ガイドラインを超える場合は、次のいずれかの対応策を実行します。
ソリューションを評価して、他の分野で埋め合わせます。
ソリューションを構築して展開するときに、これらの領域をテストおよび監視するためのフラグを付けます。
ソリューションを再設計して、容量ガイドラインを超えないようにします。
次の表は、制限を適用する Office Project Server 2007 オブジェクトの一覧と、"許容範囲のパフォーマンス" の推奨ガイドラインです。許容範囲のパフォーマンスとは、テストされるシステムがそのオブジェクト数をサポートでき、ただし、その数を超えるとパフォーマンスが低下することを意味します。アスタリスク (*) は、ハード的な制限値を示します。アスタリスクがない場合は、テスト済みまたはサポートされる制限値を示します。
| オブジェクト | 許容範囲のパフォーマンスに関するガイドライン | メモ |
|---|---|---|
ファームあたりのリソース |
40,000 |
これは、テスト済みの制限値です。 |
プロジェクトあたりの基準計画 |
7 (推奨) 11 (最大)* |
8 以上の基準計画が生成されたときに、大規模なプロジェクト ファイルに対する特定の操作でパフォーマンスの低下が見られました。詳細については、前の「パフォーマンスへの基準計画の影響」を参照してください。 |
挿入されるプロジェクトの深さ (再帰) |
16 |
このレベルでパフォーマンスの低下が重要になります。 |
挿入されるプロジェクトの広さ (非再帰) |
20 |
このレベルでパフォーマンスの低下が重要になります。 |
プロジェクトあたりのタスク |
5,000 |
これは、テスト済みの制限値です。 |
タスク期間 (月) |
300 |
プロジェクトを発行する時間は、作業時間の配分型がタスクに適用されるタスク期間によって異なります。この影響は、特に EPM Solution を使用して数年にわたるプロジェクトを作成する場合に重要になる可能性があります。 これは、テスト済みの制限値です。 |
タスクあたりの割り当て |
16,000 |
これは、テスト済みの制限値です。タスクあたり 16,000 を超える割り当てを追加できますが、既に 16,000 の割り当てがあるタスクに 1 つ割り当てを追加するために 7 秒以上かかります。 |
ローカルのユーザー設定の式フィールド |
10-30 |
タスクあたりに許されるローカルのユーザー設定の式フィールド数は、ユーザー設定フィールドの種類によって異なります。次の一覧は、ユーザー設定フィールドの種類とその制限値です。
|
サーバーあたりのエンタープライズ ユーザー設定の式フィールド |
32,000 |
これは理論上の制限値です。この制限値は、フィールドを適用できるエンティティの種類ごとに適用されます。ただし、約 1,000 以上のエンタープライズ ユーザー設定フィールドを使用したパフォーマンス テストは実施されていません。 |
チーム ビルダのリソースの制限値 |
10,000 リソース |
サーバー上にあるリソースが 10,000 の場合は、[チーム ビルダ] ダイアログ ボックスの表示に 5 秒かかりません。10,000 リソースはテスト済みの制限値ですが、その後ダイアログ ボックスの表示にかかる時間が長くなってもかまわない場合は、さらに多くのリソースがあってもチーム ビルダを使用できます。 |