パフォーマンスと容量の計画に影響を与えるその他の要因 (Office SharePoint Server)
ここでは、展開を計画する場合に考慮する必要があるその他の要因について説明します。
環境要因
コンテンツ クエリ Web パーツ
環境要因
ネットワークに関する考慮事項
ネットワークのセキュリティ
認証
カスタム コードの開発
ネットワークに関する考慮事項
ネットワークに関する考慮事項は、インストールされている Office SharePoint Server または Windows SharePoint Services のパフォーマンスに大きく影響します。パフォーマンスに影響する一般的なネットワーク コンポーネントには、次のようなものがあります。
ネットワーク インターフェイス カード (NIC)
NIC 設定 : 可能な限り、ギガビット ネットワーク カードを使用します。自動切り替えカード (100 MB/1 GB) の場合、必ず 1 ギガビットを使用するように手動設定してください。
受信/送信 : トラフィック量が多いことが予想されるシナリオでは、受信トラフィックと送信トラフィックの処理に別々の NIC を使用することをお勧めします。
スイッチ : ネットワークでスイッチを使用する場合、必ず GB スイッチを使用し、受信チャネルと送信チャネルを同数にします。
ルーター : ルーターが GB インフラストラクチャに設定されていることを確認します。
ドメイン コントローラ : ドメイン コントローラ (DC) に要求が送られる速度が DC の応答速度を上回っている場合、認証が SharePoint 環境のパフォーマンスのボトルネックになる可能性があります。NTLM などのユーザー認証を使用する環境の場合、DC と Web サーバーの割合を 1 対 3 にすることをお勧めします。この割合を 1 対 4 にしても認証負荷が許容できる場合は、サポートされる上限の 1 対 4 まで Web サーバーを追加できます。
ネットワーク構成は慎重に計画し、システムを運用環境に移行する前に徹底的にテストするようにしてください。
ネットワーク トポロジに関する推奨事項
ファーム内およびファーム間のネットワーク接続を計画します。待機時間の短いネットワークを使用することをお勧めします。
いくつかのベスト プラクティスおよび推奨事項を以下に示します。
ファーム内のすべてのサーバーは、SQL Server 2005 を実行しているサーバーに対して LAN 接続の帯域幅と待機時間 (1 ミリ秒 (ms) 以内の待機時間) を保持する必要があります。
SQL Server 2005 を実行するサーバーがファーム内の他のコンポーネントから遠く離れたワイド エリア ネットワーク (WAN) トポロジ内に配置されていて、ネットワーク遅延が 1 ms を超える環境での Office SharePoint Server 2007 の展開はテストされていません。したがって、そのような WAN トポロジはお勧めしません。
SQL Server 2005 ミラーリングまたは SQL Server 2005 ログ配布を使用してリモート サイトを最新の状態に保つ場合は、適切な WAN ネットワークを計画します。
ネットワークのセキュリティ
ネットワークのセキュリティの詳細については、「サーバー ファーム内のセキュリティ保護された通信を計画する (Office SharePoint Server)」を参照してください。
認証
環境で使用される認証機構は、システムのパフォーマンス全体に段階的な影響を及ぼします。認証パフォーマンスに関連する要因には、次のようなものがあります。
認証プロバイダへのラウンド トリップの回数と速度
認証プロバイダの処理能力
マイクロソフトで行われたテストでは、認証機構を比較すると次のような結果になりました。処理速度の速いものから順に示しています。
匿名
Kerberos
NTLM
基本
フォーム
Office SharePoint Server または Windows SharePoint Services で使用する認証プロバイダを作成する場合は、MSDN の記事「ASP.NET における認証 : .NET セキュリティ ガイド」(https://go.microsoft.com/fwlink/?linkid=98743&clcid=0x411) のベスト プラクティスのガイドラインに従ってください。
カスタム コードの開発
従来のリリースの SharePoint Server でパフォーマンスがふるわない場合、その原因の多くは、SharePoint プラットフォーム上で非効率的なカスタム機能を開発し、展開していることです。SharePoint のカスタム機能を開発する際には、数多くのパフォーマンス測定基準を監視する必要があります。次に、その一部を紹介します。
**SQL Server のラウンド トリップ。**主要なページについては、SQL ラウンド トリップを 2 ～ 3 に抑えることをお勧めします。ラウンド トリップが多すぎると、パフォーマンスに次のような悪影響が及びます。
サーバー側の処理時間が長くなるため、エンド ユーザー応答時間が長くなる。
データベース サーバーの負荷が増加するため、システム全体のスループットが低下する。
**SQL サーバーの CPU 使用率。**MOSS システムを正常に保つためには、データベース サーバーの CPU 使用率を比較的低くすることが重要です。データベース サーバーの CPU 使用率が平均で 60% を超えると、パフォーマンスに悪影響が及びます。次のような手順を実行することで、SQL Server 2005 CPU 使用率を下げることができます。
キャッシュ手法を実装する。これにより、Web サーバーからデータベース サーバーへの呼び出し回数が減ります。
目的のデータを最も効率的な方法で返すオブジェクト メソッドを使用するように、カスタム コードを最適化する (たとえば、リストに対してインデックスを導入するなど)。
SQL データベースを複数の物理データベース サーバーに分散する。
**ページのダウンロード サイズ。**コード サイズを最小限にします。ページ サイズがごくわずか増加しただけでも、そのページが毎日多くの人にアクセスされる場合、特にピーク時には、パフォーマンスに大きな影響が及びます。
**クライアント側コードの効率。**エンド ユーザー応答時間の約 50% は、返されたコードをクライアント側で処理するためにかかる時間です。カスタム ソリューションによってコードが増える場合、エンド ユーザー応答時間が悪化する可能性があります。
**AJAX コールバック。**AJAX パーツの場合、コールバックの回数と各コールバックのペイロードが問題になります。たとえば、各 KPI は結果を返すために 3 回の呼び出しを行います。ページに KPI などのカスタム コードを複数導入する場合には、ページのパフォーマンスをテストするようにしてください。
コンテンツ クエリ Web パーツ
コンテンツ クエリ Web パーツでは、Windows SharePoint Services クロス リスト クエリ機能を利用して SharePoint サイト コレクションからコンテンツを取得します。多数のリストを含むクエリを発行するように Web パーツが設定されている場合、クロス リスト クエリ機能で例外が発生する可能性があります。
既定で、クロス リスト クエリに含まれるリスト数の上限は 1,000 個です。つまり、コンテンツ クエリ Web パーツに 1,000 個を超える数のリストが含まれるクエリを設定した場合、そのクロス リスト クエリは完了せず、Web パーツにコンテンツが表示されません。この制限の目的は、SQL Server 2005 への過負荷を避けることです。クロス リスト クエリに含まれるリストの数が増えると、クエリで要求されたコンテンツがデータベース サーバーから返されるまでの時間が長くなります。リストが非常に多い場合、データベース サーバーの処理がクロス リスト クエリに偏り、他の要求が処理されなくなります。
1,000 個を超える数のリストをクエリすることが要件である場合、その処理に必要なデータベース負荷が許容できるのであれば、リスト数の上限を増やすことができます。それには、Web パーツの ListsOverride プロパティに MaxListLimit 属性を追加します。たとえば、リスト数の上限を 2000 に増やす場合、ListsOverride プロパティを次のように設定します。
<Lists ServerTemplate="850" MaxListLimit="2000">
このブックをダウンロードする
このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なブックに収められています。
入手できるすべてのブックの一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。