Jump to content 日本-日本語
製品  >  HP ProLiant サーバ  >  技術情報  >  White Paper

whitepaper

技術資料

HP ProLiant サーバ

目次

エグゼクティブ・サマリー
  概要
  ソリューションの設計
  パフォーマンスの要素
  パフォーマンス結果
  テスト対象となったシステム構成とディスクのレイアウト
  結論

PDFファイル ダウンロード

このホワイトペーパーのPDFファイルをこちらからダウンロードしてご覧下さい。
(PDFファイル、565KB)
コンテンツに進む

Microsoft SharePoint Portal Server 2003と
Microsoft Solution Accelerator for Intranets
パフォーマンス・ホワイトペーパー


パフォーマンス結果

 
ミディアムおよびラージサーバファームの構成で得られたパフォーマンスの結果を、以下に説明します。表形式で示した結果(表2)は主なリソースおよび能力のデータで、続いてテスト結果および考察を詳細に説明するセクションがあります。
 

テストで用いられた作業負荷および得られた結果は大半の顧客に対して同様であろうと予測されていますが、全てのビジネスのシナリオまたは配備トポロジに関連付けることはできません。以下に示す結果は、汎用ポータル向けに規定された構成によってもたらされた、パフォーマンスの観測結果とサポート能力を示しています。

表2に示されている個々の特定のテスト結果は、以下のとおりです。

  1. ミディアムファーム構成(5台のサーバ)
  2. ラージファーム構成(7台のサーバ)
  3. 検索サーバ固有のテスト結果
  4. ラージファーム構成および専用WSSファーム(9台のサーバ)
  5. WSSファーム固有のテスト結果

これらは、得られたテスト結果の部分的なサブセットのみを表すものですが、規範的な構成についての規模設定の主な基準のいくつかと、主なコンポーネント(検索サーバおよび専用WSSチームサイトファーム)のうちの2つも示しています。

表2 - 結果の要約

ファームの構成

1秒当たりのページ1

Web FE CPU%2

WSS CPU%3

検索 CPU%4

SQL CPU%5

クライアントKb/秒7

1 ミディアム 110 80 N/A N/A 356 5,300
2 ラージ 125 80 N/A 10 25 5,600
3 ラージ 72 90 N/A 26 15 4,800
4 ラージ+WSS 175 80 40 10 25 10,000
5 ラージ+WSS 100 5 62 0 16 7,200

注意:

  1. 1秒当たりのHTTPページのスループット(1秒当たりの操作数に相当します)
  2. Webフロントエンドの平均CPUビジー率%
  3. WSSサーバ平均CPUビジー率%
  4. 検索サーバ平均CPUビジー率%
  5. SQLサーバ平均CPUビジー率%
  6. SQLサーバはミディアムファームで2.8GHz×2システム、ラージファームで2.0GHz×4システムです。
  7. クライアントとの総ネットワークトラフィック。単位はKb/秒です

結果の分析および考察


上記の表(表2)は、いくつかの個別のテストで得られた主なリソースおよび能力のデータを示しています。次のセクションでは、この結果についてさらに考察を深めます。

ミディアムファームの構成
ミディアムファームの結果(#1)は、その規範的な構成に対するスループットの能力およびリソースの利用を示しています。

テストされたミディアムファームの構成では、1秒当たりの操作数が110というスループットが持続しました。ここで、操作はポータル機能(ブラウズ、検索、ドキュメントを開くなど)に関連するものであり、2台のMicrosoft ネットワーク負荷分散 (NLB)WebフロントエンドサーバのそれぞれでCPUの平均使用率は80%でした。(ミディアムファーム構成においてフロントエンドサーバによってサポートされる)検索操作は、全作業負荷の約15%を占め、1秒当たり約8件の検索作業を行い、各フロントエンドサーバのCPUの約8〜10%を消費しました。Microsoft SQL Server 2000を実行するアクティブなサーバのCPU平均使用率は、約35%でした(2.8GHz CPU×2)。これは、合計4台のWebフロントエンドサーバが、Microsoft SQL Server 2000を実行するアクティブなデュアルCPUのシングルサーバを有するミディアムファームによってサポートされ、1秒当たり200以上の操作を行う能力を持つことを示します。Web フロントエンドとエミュレートされたクライアントシステム間で測定されたネットワークトラフィックの速度は約5,300Kb/秒でした。ユーザが認識するパフォーマンスは、Segue Silk Performerレポートと分析によって記録された応答時間から明らかなように、簡単な機能(ホームページ、ブラウズ、ニュースの読み取りなど)については、大体において1秒足らずでした。検索操作については1.5〜2.0秒で応答し、クエリの複雑さ、参照するインデックスの数などによって変動しました。ドキュメント管理操作(チェックアウト/イン)は2.0〜2.5秒で完了しました。ドキュメントを開くには平均して3〜5秒しかかからず、ドキュメントのタイプ(Microsoft Word、Microsoft Excel、Microsoft PowerPointなど)およびドキュメントのサイズにより異なりました。言うまでもなく、ドキュメントのサイズが大きくなるとクライアントデスクトップへの転送により長く時間がかかりました。

ラージファームの構成
ミディアムファームの構成の結果を(#1)をラージファームの構成(#2)と比較すると、ラージファームへのアップグレードと、2台の専用検索サーバ配備の効果がわかります。

テストされたラージファームの構成では1秒当たりの操作数が125というスループットが持続しました。ここで、操作はポータル機能(ブラウズ、検索、ドキュメントを開くなど)に関連するものであり、2台のMicrosoft ネットワーク負荷分散 (NLB)Webフロントエンドサーバのそれぞれで、CPUの平均使用率は80%でした。Microsoft SQL Server 2000を実行するアクティブサーバのCPUの平均使用率は約25%でした(2.0GHz CPU×4)。これは、6台のWeb フロントエンドサーバがMicrosoft SQL Server 2000を実行するアクティブな4-CPUのシングルサーバを有するラージファームによってサポートされ、1秒当たり約375の操作を行う能力を持つことを示します。Webフロントエンドとエミュレートされたクライアントシステム間で測定されたネットワークトラフィックの速度は約5,600Kb/秒でした。2台の専用検索サーバにおける検索サービスは(作業負荷の定義にしたがって)1秒当たり約8件の検索作業をサポートし、各検索サーバでは約4.5%だけCPUを消費します。検索サーバの最大能力については、次のセクションでより詳しく説明します。ユーザが認識するパフォーマンスはミディアムファームと同様で、簡単な機能(ホームページ、ブラウズ、ニュースの読み取りなど)については、大体において1秒足らずでした。検索操作については1.5〜2.0秒で応答し、クエリの複雑さ、参照するインデックスの数などによって変動しました。ドキュメント管理の操作(チェックアウト/イン)は2.0〜2.5秒で完了しました。ドキュメントを開くには平均して3〜5秒しかかからず、ドキュメントのタイプ(Microsoft Word、Microsoft Excel、Microsoft PowerPointなど)およびドキュメントのサイズにより異なりました。言うまでもなく、ドキュメントのサイズが大きくなるとクライアントデスクトップへの転送により長く時間がかかりました。

この結果を見ると、テスト対象となったMicrosoft SQL Server 2000を実行するHP ProLiant DL580 4 × 2.0GHzサーバは、装備されている4つのCPUのうち2つのみが稼動する、テストでの負荷およびフロントエンド/検索構成をサポートできたことになります。しかし、さらに多くのフロントエンドサーバまたは専用Microsoft Windows SharePoint Servicesサーバファームを追加するには、Microsoft SQL Server 2000を実行するサーバで、3つ以上のCPUを必要とします。したがってMicrosoft SQL Server 2000を実行するラージファームサーバに適した選択として、4-CPU対応のシステムをお勧めします。最初に2-CPUシステムとして配備し、別途フロントエンドの機能(およびMicrosoft SQL Serverの機能)が必要になったときに、後でCPUを追加することによってアップグレードできます。Microsoft SQL Server 2000の実行に関して2-CPUと4-CPUサーバの利点を比較したものについては、後のセクションでより詳しく、つまり、専用WSSファームの追加に関するパフォーマンス上の利点、個々の検索サーバのパフォーマンス、およびインデックスサーバのパフォーマンスなどに関して、考察します。

専用検索サーバ
検索サーバのテスト結果(#3)から、検索サーバの潜在的な最大能力がわかります。

テストで用いられたトータルの作業負荷は、検索操作のパーセンテージを含み、10〜25%の間で、特定のポータル(たとえば全社レベルポータルと事業部ポータルなど)の作業負荷のコンポーネントによって異なりました。この結果より、1秒当たり約8〜10件という検索の速度であることが示され、専用検索サーバへの負荷が小さいことが判明しました。したがって追加のテストは全作業負荷のうち検索操作の部分のみを使って実行され、2.8GHz CPU×2の専用検索サーバのトータルな能力が決定されました。WebフロントエンドサーバのCPU使用率が90%になるまで、負荷が増やされました(検索/秒)。その負荷レベルでは、専用の検索シングルサーバは1秒当たり72件の検索を行い、CPUの使用率は26%でした。検索サーバからのネットワークトラフィックは、平均で4,800Kb/秒でした。これらの結果から推定すると、専用の検索シングルサーバは、全負荷(平均のCPUビジー率80%)で1秒当たり210件以上の検索をサポートすることができます。これはトータルのパフォーマンスというより高可用性の問題ですが、専用検索サーバを2台配備することはラージファームの構成ではできません。

このテストで注目すべきなのは、システムのパフォーマンスモニタは検索サービスに対して1秒当たり平均115クエリをレポーティングしていたのに対し、クライアントは1秒当たり平均72ページを受け取っていたこと(これは結果を返す検索操作に直接関連します)です。この差異は、レポーティングされた1秒当たりのページが、1秒当たりの検索操作の数に直接関連するという事実によって説明することができます。一方、レポーティングされる1秒当たりのクエリは、検索範囲に渡って参照される全てのコンテンツのインデックスに対して検索サービスが発行する全クエリに関連しています。このテストで用いられた検索の作業負荷のコンポーネントは、5つの異なる検索範囲からランダムにピックアップされました。最初の検索範囲は、使用するインデックス全てに含まれる全ポータルコンテンツを参照する、「全てのソース」で、HPのテストケースでは、4つのインデックスが使用されました。他の4つの検索範囲では、単一のインデックスに関連する個々の事業部のコンテンツソースに範囲を狭めました。したがって検索操作の80%は1つのインデックスに対して単一のクエリとなり、一方検索操作の20%によって4つのクエリが4つのインデックスに対して発行されます。これは、1秒当たり72の検索をサポートするには115のクエリが必要であることを示しています(1.60:1の比率)。この比率は、ポータルの使用を実際に試すことによって、検索範囲やアクセスするインデックスを決定する上で、非常に有用です。システムのパフォーマンスモニタは、1秒当たりのクエリのレポーティングを行います。しかし、上記の理由により1秒当たりのポータルの検索を直接レポーティングすることはできません。ただし、顧客はシステムのモニタ経由で自身のクエリ/秒を決定し、決定したクエリと検索の比率を用いて1秒当たりの実際の検索スループットを算出することができます。

専用Microsoft Windows SharePoint Services (WSS)ファーム
前述の結果は、ラージファーム構成についての結果 (1秒当たり約125の操作のスループットが持続されました)ですが、さらに次のような追加のテストが実施され、専用Microsoft Windows SharePoint Services (WSS)ファームのパフォーマンスについての判定が行われました。その追加テストとは、(1)「標準的な」作業負荷(ユーザの40%はチームサイトのユーザです)を拡張されたラージファーム+ Microsoft Windows SharePoint Servicesのファームの構成に適用すること(表2のテスト#4)、(2)「チームサイトのユーザのみ」の作業負荷を適用してMicrosoft Windows SharePoint Servicesのファームのパフォーマンスを試すこと(表2のテスト#5)のの2つです。

専用Microsoft Windows SharePoint Servicesファーム(合計9台のサーバ)により全作業負荷が増強された構成に適用した結果、1秒当たり175ページのスループットを持続し、WebフロントエンドサーバはCPUビジー率80%で動作し、Microsoft Windows SharePoint Servicesサーバはビジー率約40%で動作しました。Microsoft SQL Server 2000を実行するアクティブなシングルサーバでは、平均してCPUビジー率は約25%でした。エミュレートされたクライアントが受け取る全ネットワークトラフィックは、平均で約10,000Kb/秒でした。その他の応答時間を測定したところ、簡単な操作については、多くの場合、1秒足らずであり、結果を返す検索は1〜2秒で設定され(範囲および複雑さにより異なります)、ドキュメント管理操作には2〜3秒を要しました。したがって、新しい専用ファームはWebフロントエンドサーバが提供するShared Servicesを使用していましたが、トータルのスループットは増加し、ユーザ関連のパフォーマンスレベルは維持されました。なお、チームサイトの作業に偏向したユーザの母集団および作業負荷の組み合わせでは、専用Microsoft Windows SharePoint Servicesファームをより多く利用し(代わりにWebフロントエンドサーバはあまり使用せず)、作業負荷とユーザの組み合わせの例を使用して測定された能力に全能力が追加されることに注意が必要です。

「チームサイトのユーザのみ」のテストでは、専用Microsoft Windows SharePoint Servicesファームが平均62%のCPU使用率で1秒当たり100の操作を実行し、クライアントの全ネットワークトラフィックは7,200Kb/秒でした。SQLサーバのCPUは平均16%でした。

インデックスサーバの動作およびパフォーマンス
Microsoft SharePoint Portal 2003によって、コンテンツのソース(およびインデックス)へのフレッシュな情報の提供を指定できるようになるという点については、その解釈にはかなり大きな許容範囲があります。再インデックス作成の方法およびそれぞれの頻度はビジネスニーズに左右されます。適切な方法を選択する際に、ビジネスで必要となるデータの「新しさ」と、消費されるインデックスサーバのリソースとのトレードオフが生じ、ポータルコンテンツとしてMicrosoft SQL Server 2000を実行するサーバへの影響がスキャンされ、インデックスが作成されます。再インデックスの作成には4つの方法があります。すなわち、Full、Incremental、Incremental (inclusive)、およびAdaptiveです。この4つの方法とその様々なパラメータ設定の詳細な調査についてはこのホワイトペーパーでは触れませんが、4つの方法の目的や操作について理解を深めるためには、『SharePoint 2003 Administrator’s Guide』をご覧になることをお勧めします。ただし、パフォーマンスへの影響という観点では、「Full」インデックスでは初めからインデックスを完全に再構築し、インデックスのコンテンツのソースに多くの項目が含まれる場合はかなり時間がかかることを理解することが重要です。こうした理由から、「Full」インデックスはあまり実行されず、ピーク時以外の場合のみ実行されます。対照的に、「Incremental」再インデックスは、新しい項目または最後のインデックス作成操作の後変更された項目のみを扱います。これは、ソリューションで使用されている残りのサーバまたはユーザが認識するパフォーマンスに重大な影響を及ぼすことなく、ビジネスニーズに適合するために必要になる度にインデックス作成が行われるように(たとえば30分ごと)設定できます。「Adaptive」インデックスの操作では、履歴データが頻繁に変更される項目に着目してその項目により重点を置き、結果として実際のドキュメントの変更パターンに適合することができるため、より効率的です。

パフォーマンスの指標とするために、ラージファームインデックスサーバ(2.8GHz CPU×2)でテストを実施し、インデックスのスループットを調べました。合計600,000を超える項目を含むコンテンツのソースの「Full」インデックス操作には、最初は約24時間を要しました。以下で考察するように、Microsoft SQL Server 2000を実行するサーバのディスクおよびサーバメンテナンスを実施したところ、18時間に短縮されました。次に「Incremental (inclusive)」再インデックスを、別のテスト実施後、同じインデックスで実施しました(これによりかなり多くのドキュメントが変更されます)。この「Incremental」再インデックスは1時間で完了しました。さらに、(前のチェックアウトの後)ドキュメントをチェックインする場合は再インデックス作成も自動的に行われます。テストで用いられた作業負荷には、この作業のパーセンテージが含まれています。これらのテスト実行中に、このチェックインされたドキュメントのインデックス作成の作業がインデックスサーバ上での最小の負荷であることが判明しました。

ディスク(論理ディスクボリューム)管理は、特にディスクのフラグメンテーションの点で、インデックス作成(および次の検索)の操作に大きな影響を及ぼすことが明らかになりました。Lab.のテストでのインデックスサーバと検索サーバには専用の論理ボリュームが用いられ、必要な検索カタログおよび関連ファイルを保存しました。この結果、このインデックスサーバのディスクボリュームでいくつかの再インデックス作成操作の後フラグメントが生じ、全体的なインデックス作成処理を遅らせることが判明しました。さらに、修正された検索カタログが増え、それぞれの再インデックス作成後マージされたため、検索サーバのディスクでも多少フラグメントが生じました。ディスクフラグメンテーションのレベルを監視し、必要に応じて修正を行うことはよい方策です。Microsoft SQL Server 2000を実行するサーバに対するサーバ・ディスク・デフラグメンテーション(データおよびログ ディスク)を行うことで、パフォーマンスが向上しました。ただし、Microsoft SQL Server 2000はこの操作の間停止しなければならず、ユーザはポータルを使用できません。したがってメンテナンス期間についてスケジューリングが必要です。テストシステムのデータベースのデータディスクをデフラグメンテーションするには数時間を要し、データベースのログディスクには約20分を要しました。

Microsoft SQL Server 2000を実行するサーバのデータベーステーブルに定期的に再インデックス作成を行うことで、パフォーマンスは大きく向上しました。この手順はMicrosoft Solution Accelerator for Intranets Content Providerのツールドキュメントに記載されており、大量のコンテンツがシステムに追加された後この操作を行うよう記載されています。定期的に使用することもお勧めします。このドキュメントに記載された手順はクエリとしても適用でき、これによってデータベースのテーブルのデータはリセットされ、データベースのテーブルの再インデックス作成が行われます。これにより、テーブル分割がなくなり、結果としてデータベースのインデックス操作がより効率的に行われるようになります。ポータルコンテンツの再インデックス作成のパフォーマンスへのポジティブな影響も重要です。なお、ディスクおよびデータベースのメンテナンスを実行すると、「Full」インデックスの実行時間が24時間から18時間に短縮されます。

Microsoft SQL Server 2000のパフォーマンスおよびスケーリング
前のセクションでは、他のコンポーネント(たとえば2台のMicrosoftネットワーク負荷分散Webフロントエンドサーバ)が飽和状態になったとき、Microsoft SQL Server 2000を実行するアクティブなサーバは、多くの場合、CPUビジー率が平均25%以下であることを説明しました。さらにフロントエンドサーバを追加すると、最終的に飽和状態に至るまでMicrosoft SQL Server 2000を実行するサーバの負荷が明らかに増えます。ベストプラクティスでは、4:1(フロントエンドのCPU : Microsoft SQL Server 2000を実行するサーバのCPU)という比率が推奨される最大比(または前述したように、Microsoft SQL Server 2000を実行するために4-CPUサーバを使用する場合は、6:1)です。ビジー状態中にパフォーマンスが低下しないように、予想されるピークの条件に対してソリューションのコンポーネントの規模を設定することが重要です。これは、Microsoft SQL Server 2000を実行するクラスタサーバシステムに対しても同様です。2-サーバアクティブ/パッシブクラスタについては、アクティブなシングルサーバが、必要とされる全ての負荷をサポートできるように、システムの規模を設定しなければなりません。アクティブ/アクティブクラスタを配備する際には、両者を組み合わせて全負荷をサポートするようにサーバを構成する傾向にあります。しかし、一方に障害が生じた場合は、パフォーマンスに重要な影響を及ぼします。通常ITのベストプラクティスでは、全ての負荷をサポートするために複数のアクティブなクラスタノードが必要なときは、いわゆる「N+1」冗長クラスタを配備します(N個のアクティブなノード、プラス1つのパッシブなノード)。この方法では、アクティブなノードに障害が発生した場合でも、有効なパッシブノードがあるため、フェールオーバによりパフォーマンスの低下を防ぐことができます。その他のソリューションとしては、たとえば2-ノードのアクティブ/アクティブクラスタを実行するが、それぞれが全負荷の半分を処理し、いずれかに障害が発生した場合でも全負荷を処理できるように、システムの規模を設定することです。「N+1」冗長配備が推奨される方法です。

ネットワークの利用
推奨するCPU制限のシステムでパフォーマンスを達成することは、他の二次的なリソース(メモリ、ディスク、およびネットワーク)が飽和しない場合のみ、可能です。上記の結果が示すように、高スループットレベルでネットワークの帯域幅を利用することが重要です。MicrosoftおよびHPのテストLab.でのテスト結果から、こうした潜在的な高い負荷を処理するためには、規範的なネットワーク・アーキテクチャの開発が必要であることがわかりました。これらの推奨されるネットワーク設計では、ネットワークトラフィックをセグメント化するために複数のバーチャルLANが提供されます。またこのネットワーク設計については『Microsoft Solution Accelerator for Intranetss Build and Test Guide』の第2章に記載されています。


一般的な能力のガイドライン


これまでの分析結果から、一般的な能力のガイドラインをいくつかまとめました。表3にサポート可能なフロントエンドのサーバの数が示されていますが、これは全て、(アクティブ/パッシブクラスタで動作している)Microsoft SQL Server 2000を実行しているシングルサーバがパフォーマンスを制約する要因であることを前提としています。結果はテストで用いられた作業負荷からも予測されます。

表3. 構成およびコンポーネントの能力

構成またはコンポーネント

おおよその能力 (操作数/秒)

Webフロントエンド/検索サーバ
(または既存のミディアムファームを増強)*
50
Webフロントエンドサーバ(またはラージファームを増強)* 60
専用検索サーバ(ラージファーム上)* 210
WSSサーバ(または専用WSSファームを増強)* 65
最大のミディアムファームの能力
(2-cpu SQLサーバ×1、 4 フロントエンド)**
220
最大のラージファームの能力
(4-CPU SQLサーバ×1、6 F-E、2 検索)**
375
最大のラージファームの能力
(4-CPU SQLサーバ×1、4 F-E、2 検索 + WSSファーム)**
500
注意: 記号(*)の付いた結果はそれぞれの特定のコンポーネントサーバについての能力であり、記号(**)の付いた結果は、1台のサーバを使用してMicrosoft SQL Server 2000を実行する完全なミディアムまたはラージファームのソリューションについての能力です。

表3の結果は、SharePoint V2およびWindows SharePoint Servicesのアーキテクチャのスケーラビリティが非常に高いことを示しています。テストされた様々な規範的な構成は、様々な能力レベルを必要とする顧客に対し基本レベルのソリューション設計を提供するものであり、ある範囲の拡張のニーズや様々な作業負荷の組み合わせに適合させるための拡張パスとして十分にドキュメント化され、理解されています。

 

前のページへ 次のページへ
PDFファイルをご覧いただくには、Adobe® Reader® が必要です。
アドビシステムズ社のウェブサイト より、ダウンロード(無料)の上ご覧ください。
印刷用画面へ印刷用画面へ
プライバシー ご利用条件・免責事項