パフォーマンスおよび容量のその他の計画要因 (Windows SharePoint Services)
このセクションでは、容量およびパフォーマンスを計画するときに考慮する必要があるその他の要因について説明します。
環境要因
ネットワーク構成
ネットワーク セキュリティ
認証
カスタム コードの開発
ネットワーク構成
ネットワーク構成は、Windows SharePoint Services インストールのパフォーマンスにとって重要です。パフォーマンスに影響する一般的なネットワーク コンポーネントは以下のとおりです。
ネットワーク インターフェイス カード (NIC)
NIC 設定 : 可能な場合は常に、ギガビット ネットワーク カードを使用してください。セルフスイッチング カード (100 MB/1 GB) の場合は、常に 1 ギガビットを使用するようにオーバーライドを設定してください。
受信/送信 : 大量のトラフィックが予想されるシナリオの場合、別々の NIC で受信トラフィックと送信トラフィックを処理することをお勧めします。
スイッチ : スイッチを介してネットワークを運用している場合は、必ず GB スイッチを使用し、受信チャネル数と送信チャネル数を同じにします。
ルーター : ルーターは必ず GB インフラストラクチャ上で構成します。
ドメイン コントローラ : ドメイン コントローラ (DC) がその応答能力以上の速度で要求を受信する場合、認証が SharePoint 環境でのパフォーマンスのボトルネックとなる可能性があります。NTLM などのユーザー認証を使用した環境の場合は、DC あたりの WFE を 3 台にすることをお勧めします。テストの結果、DC あたり 3 台の WFE で認証負荷が許容範囲内にあるとわかれば、DC あたりの WFE をもう 1 台追加できます (サポートされる限界値である DC あたり 4 台の WFE)。
システムを運用環境に移す前に、十分にネットワーク構成を計画してテストする必要があることに留意してください。
ネットワーク セキュリティ
ネットワーク セキュリティの詳細については、「サーバー ファーム内でセキュリティ保護された通信を計画する (Windows SharePoint Services)」を参照してください。
認証
環境で使用されている認証機構は、システム全体のパフォーマンスに少々影響します。認証のパフォーマンスに影響する要因は次のとおりです。
認証プロバイダへのラウンド トリップの数と速度
認証プロバイダの処理パフォーマンス
Microsoft のテストでは、認証機構の順序 (高速なものから低速なもの) は次の結果を示しています。
匿名
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 サーバーでの負荷の増大によるシステム全体のスループットの低下
SQL サーバーでの CPU 使用率。 システムが正常な状態を維持するには、SQL サーバーでの CPU 使用率が比較的低く保たれていることが重要です。SQL サーバーでの CPU 使用率が平均 60% 以上になると、パフォーマンスに悪影響が及びます。SQL サーバーでの CPU 使用率を軽減するために実行可能な手順は以下のとおりです。
キャッシュ手法を実装する – これにより、WFE から SQL Server への呼び出しの合計数が軽減します。
最も効率的な方法 (リストにインデックスを導入するなど) で必要なデータを返すオブジェクト メソッドを使用するようにカスタム コードを最適化する。
複数の物理的な SQL サーバーに SQL データベースを分散する。
ページのダウンロード サイズ。 コード サイズを最小限に抑えます。ページ サイズが比較的小さく増加しただけで、毎日多数のユーザーからそのページへのアクセスがある場合は、特にピーク時にパフォーマンスに大きく影響する可能性があります。
クライアント側のコードの効率性。 エンド ユーザーの応答時間の約 50% が、クライアント側での返されたコードの処理に費やされています。カスタム ソリューションにより、このようなコードが増える場合、エンド ユーザーの応答時間に悪影響が及ぶと予想できます。
AJAX コールバック。 AJAX パーツの場合、コールバックの数と各コールバックのペイロード。たとえば、それぞれの KPI は結果を返すために 3 つの呼び出しを行います。複数の KPI または他のカスタム コードをページに導入する場合は、ページのパフォーマンスを必ずテストしてください。
このドキュメントをダウンロードする
このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なドキュメントに収められています。
入手可能なドキュメントの詳細な一覧については、「Windows SharePoint Services 3.0 テクニカル ライブラリ」を参照してください。