WAN 環境用に Office SharePoint Server を最適化する

[アーティクル]
06/12/2012

この記事の内容 :

WAN のトポロジを設計する
コンテンツのクロールプロセスを最適化する
WAN アクセラレータと他のサードパーティツール
ダウンロードの時間が短くなるようにページを設計する
WAN 環境でのキャッシュを最適化する

ここでは、ワイドエリアネットワーク (WAN) 環境でのパフォーマンスが向上するように Microsoft Office SharePoint Server 2007 ソリューションを最適化する具体的な方法について説明します。

WAN のトポロジを設計する

Office SharePoint Server 2007 ファームでのサーバーの役割を柔軟に構成して、特定のパフォーマンス要件または可用性要件に合うように最適化できます。WAN 環境でのサーバーの役割には、理解しておく必要のある重要な技術的特性がいくつかあります。パフォーマンスと可用性の全体的な要件を計画するだけでなく、これらの特性を理解しておくと、WAN 環境用のサーバーファームトポロジの最適化に役立ちます。

コンテンツのクロールのためにトポロジを最適化する

既定では、Office SharePoint Server 2007 はすべての Web サーバーを使用して、サーバーファーム内のコンテンツをクロールします。クロールにすべての Web サーバーを使用するようにサーバーファームを構成すると、インデックスサーバーはファーム内の各 Web サーバーに要求を送信します。

ファーム内のコンテンツをクロールすると、Web サーバーに大きな負荷がかかります。これはネットワークトラフィックの急増につながり、また、CPU とメモリを大量に消費します。ファーム内のコンテンツをクロールすると、ユーザー要求よりも多くのトラフィックがネットワーク上に発生する可能性があります。このようなネットワークトラフィックは、サーバーファーム内のすべての Web サーバーのパフォーマンスに悪影響を及ぼし、その結果、SharePoint サイトのコンテンツに対するエンドユーザーの要求への応答時間が長くなる可能性があります。

WAN 環境では、コンテンツのクロール用に専用の Web サーバーを構成することをお勧めします。特に、500 GB を超えるコンテンツを含むサーバーファームをクロールする場合、または WAN 経由でコンテンツをクロールする場合は、強く推奨されます。コンテンツクロールがユーザーの要求に影響を与えないようにするには、専用の Web サーバーをネットワーク負荷分散のローテーションから除外します。クロールジョブをスケジュールする可能性が最も高い地域ファームのオフピーク時間帯が、中央ファームではピーク時間帯に当たってしまうようなグローバル環境では、このことが特に重要です。

ローカルコンテンツクロールの専用 Web サーバーを構成する

ファームのローカルなコンテンツをクロールするときのパフォーマンスを最適にするには、インデックスサーバーに両方の役割対応できるだけのメモリ容量がある場合は、インデックスサーバーをクロール用の専用 Web サーバーとして構成します。

次の図は、コンテンツのインデックス作成用に専用 Web サーバーを使用して最適化したファームを示しています。

WAN トポロジでの SharePoint Server

インデックスサーバーと専用 Web サーバーの両方に同じサーバーを使用することで、コンテンツをクロールするときにインデックスサーバーは別のサーバーに要求を送信する必要がなくなります。その結果、クロールのパフォーマンスは向上し、ネットワーク上の全体的なトラフィックは減少します。このような構成を実現できない場合は、サーバーファーム内の別のサーバーを使用してもかまいません。

次のどちらかの方法を使用して、専用 Web サーバーを使用するようにインデクサを構成できます。

[サーバーの管理] で Office SharePoint Server Search Service を構成します。
hosts ファイルを直接編集します。

詳細については、以下のリソースを参照してください。

リモートファームのクロール用に専用 Web サーバーを構成する

地域ファーム上にあるコンテンツをクロールするときの地域ファームのパフォーマンスを最大化するには、中央ファーム上にインデックスサーバーを構成し、地域ファームにある専用 Web サーバーを使用します。

次の図は、コンテンツのインデックス作成用に専用 Web サーバーを使用してそれぞれ最適化した 2 つの地域ファームを示しています。

地域ファーム 1 では、サーバーは Web サーバーの役割専用です。中央ファームと地域ファーム 1 の両方が、この専用 Web サーバーをコンテンツのクロールに使用します。
地域ファーム 2 は、中央ファームと同様の構成で、Web サーバーの役割もインデックスサーバーに展開されています。

WAN に合わせた Office SharePoint Server の最適化

中央ファームのインデックスサーバーがリモートファームのコンテンツをクロールするときに、中央ファームの Web サーバーの役割を使用しないことに注意してください。インデックスサーバーは、リモートファームの Web サーバーに直接アクセスします。

前の図で、地域ファームでコンテンツをクロールしているときに、同時に中央ファームでもクロールを行う場合は、地域ファーム 1 の構成によってパフォーマンスが次のように向上します。

専用 Web サーバーが別のサーバー上にあるので、地域ファーム 1 でのローカルクロールのパフォーマンスは向上します。その結果、中央ファームはインデックスサーバーのパフォーマンスに影響しません。
WAN 経由でのクロール時間が向上します。地域ファームの専用 Web サーバーは、インデックスサーバーとの共有サーバー上にある場合よりも応答性が向上するので、クロールに要する時間が短くなります。
中央ファームのインデックスサーバーは専用 Web サーバーと通信するようになるので、中央ファームのクロールプロセスが向上します。

地域ファーム 2 で示されているトポロジ構成を実装する場合は、2 つのフォームでのクロールプロセスを重ならないようにスケジュールすることで、パフォーマンスを最適化できます。

リモートファームの専用 Web サーバーを使用してコンテンツをクロールするには、hosts ファイルを直接編集する必要があります。リモートファームではなく、コンテンツをクロールするファームの hosts ファイルを編集することに注意してください。

中央ファームが地域ファームのコンテンツをクロールするグローバルソリューションでは、hosts ファイルを編集して、クロール対象の各地域ファームに存在する各 Web アプリケーションのエントリを追加します。hosts ファイルのエントリでは、専用 Web サーバーの IP アドレスの後に、Web アプリケーションの名前を記述します。次に例を示します。

10.10.10.4 TeamSites
10.10.10.4 MySites
10.10.10.4 Marketing
10.10.10.4 Sales

詳細については、「Hosts ファイルを編集して、クロール専用のフロントエンド Web サーバーを構成する (Office SharePoint Server 2007)」を参照してください。

クエリのパフォーマンスのために最適化する

ユーザーにとって、クエリのパフォーマンスは、Office SharePoint Server 2007 を WAN 環境に展開するときの重要な考慮事項です。ユーザーが発行したクエリは、Web サーバーに送信されます。Web サーバーは、クエリサーバーと通信して結果の一覧を作成した後、Microsoft SQL Server を実行するコンピュータと通信して、要約テキスト、URL、およびセキュリティによるトリミングで結果の一覧を拡張します。

クエリ結果を返すためにサーバー間通信が必要な場合は、クエリのパフォーマンスを最適化するトポロジを構成できます。サーバーファーム内だけでの最適化により、クライアントコンピュータとサーバーの間の WAN 経由で認識される全体的なパフォーマンスが向上する可能性があります。

最も重要な最適化は、前のセクションで説明したように、コンテンツのクロールに専用 Web サーバーを使用することです。これにより、Web サーバーはユーザー要求に応じるために確保され、インデックス作成ジョブによって過負荷になることはありません。

次に、クエリの役割の展開に関して別のオプションがいくつかあり、それぞれが異なる種類の最適化を提供しています。個々のオプションにより、クエリ要求に対する最適な対応と、ファームサーバー間のローカルネットワーク上のネットワークトリップの抑制の間の、バランスの取り方が異なります。次の表では、これらの構成オプションをまとめて、各オプションのトレードオフについて説明します。

構成	トレードオフ
すべての Web サーバーにクエリの役割を展開する。	クエリの役割を Web サーバーでホストし、ファーム内のサーバー間のラウンドトリップ通信を削減できます。その結果、クエリのパフォーマンスが最適化されます。ただし、2 つのサーバーの役割が同じサーバーでホストされているので、これらのサーバーの使用量が増えると、Web サーバーの全体的なパフォーマンスが影響を受ける可能性があります。したがって、ピーク時のユーザー要求を処理するのに十分な Web サーバーを展開する必要があります。この構成ではユーザーのクエリのパフォーマンスが最適化されますが、ファームのバックエンドに関するトレードオフがあります。インデックスサーバーは、インデックスカタログをファーム内の各クエリサーバーに伝達します。クエリの役割を複数の Web サーバーに展開すると、インデックスの伝達時に必要なサーバーリソースが増加します。
1 つまたは複数のサーバーをクエリの役割専用にする。	クエリの役割をホストするために専用のサーバーを 1 つ以上用意すると、これらのサーバーは、利用できるすべてのリソースを使用して役割を効率よく実行するように最適化されます。また、この構成では、通常、展開するクエリサーバーの数が少なくなります。ただし、この構成では、Web サーバーからのクエリ要求に対応するため、またインデックスの伝達時にコンテンツのインデックスを更新するために、ファーム内のサーバー間で必要なラウンドトリップ通信が増加します。
クエリとインデックスの役割を同じサーバーに展開する。	クエリの役割とインデックスの役割を同じサーバーに展開できます。このようにすると、インデックスの伝達が不要になるので、ファームの通信が最適化されます。ただし、この構成では、クエリの役割をホストできるサーバーの数が 1 つのみに制限されます。これは、インデックスサーバーにクエリの役割を展開すると、インデックスサーバーはファーム内の他のサーバーにコンテンツインデックスを伝達できなくなるからです。

すべての Web サーバーにクエリの役割を展開する。

クエリの役割を Web サーバーでホストし、ファーム内のサーバー間のラウンドトリップ通信を削減できます。その結果、クエリのパフォーマンスが最適化されます。

ただし、2 つのサーバーの役割が同じサーバーでホストされているので、これらのサーバーの使用量が増えると、Web サーバーの全体的なパフォーマンスが影響を受ける可能性があります。したがって、ピーク時のユーザー要求を処理するのに十分な Web サーバーを展開する必要があります。

この構成ではユーザーのクエリのパフォーマンスが最適化されますが、ファームのバックエンドに関するトレードオフがあります。インデックスサーバーは、インデックスカタログをファーム内の各クエリサーバーに伝達します。クエリの役割を複数の Web サーバーに展開すると、インデックスの伝達時に必要なサーバーリソースが増加します。

1 つまたは複数のサーバーをクエリの役割専用にする。

クエリの役割をホストするために専用のサーバーを 1 つ以上用意すると、これらのサーバーは、利用できるすべてのリソースを使用して役割を効率よく実行するように最適化されます。また、この構成では、通常、展開するクエリサーバーの数が少なくなります。

ただし、この構成では、Web サーバーからのクエリ要求に対応するため、またインデックスの伝達時にコンテンツのインデックスを更新するために、ファーム内のサーバー間で必要なラウンドトリップ通信が増加します。

クエリとインデックスの役割を同じサーバーに展開する。

クエリの役割とインデックスの役割を同じサーバーに展開できます。このようにすると、インデックスの伝達が不要になるので、ファームの通信が最適化されます。

ただし、この構成では、クエリの役割をホストできるサーバーの数が 1 つのみに制限されます。これは、インデックスサーバーにクエリの役割を展開すると、インデックスサーバーはファーム内の他のサーバーにコンテンツインデックスを伝達できなくなるからです。

単一のファームをクエリのパフォーマンスに対して最適化できるだけでなく、マルチファームのシナリオを最適化するためのオプションもいくつかあります。

親ファームが子ファームに対して検索サービスを提供するファーム間共有サービスのシナリオでは、親ファームに専用のクエリサーバーを展開することで、親ファームは、親ファームでの他のユーザー操作のパフォーマンスに影響を与えることなく、子ファームからの検索クエリを処理できます。このシナリオでは、子ファーム上の Web サーバーは、親ファーム上の Web サーバーを通して通信するのではなく、親ファームのクエリサーバーとデータベースサーバーに直接接続します。親ファームが子ファームにサービスを提供するファーム間共有サービスは、WAN 経由ではサポートされないことに注意してください。ただし、大規模な組織では、サービスを提供する親ファームと、サイトおよびコンテンツを提供する子ファームが、1 つのセントラルサイトに含まれる場合があります。このようなシナリオでは、セントラルサイトのユーザーにサイトとコンテンツを提供するセントラルサイトの子ファームのパフォーマンスに影響を与えることなく、地理的に分散したマルチファーム環境内の地域ファーム上のコンテンツをクロールするように、親ファームを構成できます。
中央ファームが地域ファームのコンテンツをクロールする、地理的に分散しているマルチファーム環境では、以下の方法でサーバーを構成することにより、コンテンツのクロールとクエリの両方のパフォーマンスを最適化できます。
- すべてのファームで、インデックスサーバーに Web サーバーの役割を展開します。このサーバーをネットワーク負荷分散ローテーションから除外し、この専用 Web サーバーを使用してコンテンツをクロールするように親ファームのクロールプロセスを構成します。
- 各ファームのすべての負荷分散された Web サーバーに、クエリサーバーを展開します。

ファームサーバーを地理的に分離する

ユーザーの要求に適切に対応し、パフォーマンスボトルネックの発生を防ぐには、サーバーファーム内のサーバー間の通信用に堅牢なネットワーク接続が必要です。標準的なネットワーク要件として、サーバーファーム内のすべてのサーバーは、同じローカルエリアネットワーク (LAN) の同じデータセンター内に存在する必要があります。複数の WAN リンクにわたるファームサーバーの分離は、サポートされていません。

このガイダンスに加えて、1 つ以上の Web サーバーを他のファームサーバーとは地理的に異なる位置に配置できるようにする、固有の要件があります。このシナリオでは、Web サーバーは異なるデータセンターに存在しますが、SQL Server を実行するコンピュータと同じ LAN に接続されます。

注意

次のガイダンスでは、これまで文書化されていない展開シナリオに関するサポート可能性の要件を示します。

このシナリオのガイダンスはまだ暫定的なもので、今後のテストによって変更される場合があります。このガイダンスは、正式なテストに基づくガイダンスが提供されるまでの間、テストおよび展開を行うためのガイドラインとして使用できます。これらのガイドラインをユーザー固有の環境におけるテストでの基礎として使用し、品質およびパフォーマンスのしきい値を独自に決定してください。

このシナリオは、商用レベルでの妥当なサポートによってサポートされます。さらに詳細なテストまたは独自環境内での実行結果により、このシナリオで重大な問題が発生することが判明した場合は、Web サーバーをデータベースサーバーの近くに移動する必要があります (それによって問題が解決される場合)。

この展開シナリオは、次の条件が成立する状況において暫定的なサポート可能性の要件を満たすことを意図しています。

Web サーバーとデータベースサーバーの間のネットワークリンクの遅延が、1 ミリ秒 (ms) 未満であること。この遅延条件を満たすには、Web サーバーがデータベースサーバーから 10 マイル (約 16 km) 以内に存在することが理想です。最適なネットワーク構成においては、最高 100 マイル (約 160 km) までは 1 ms 未満の遅延を達成できますが、そのような状況はまれです。距離が 10 ～ 100 マイルの場合は、ネットワークおよびハードウェアのプロバイダに問い合わせて、遅延が 1 ms 未満のサービスレベルを提供できるかどうかを確認してください。100 マイルを超える距離でのファームサーバーの分離はサポートされていません。同じファームのサーバーをホストする 2 つのデータセンター間の遅延を測定するときは、Ping ツールを使用して、リモートデータセンター内の Web サーバーからプライマリデータセンター内のデータベースサーバーに対して遅延を測定します。往復の結果を 2 で割ります。
Web サーバーとファーム内の他のサーバーとの間のトラフィックを処理するのに十分な帯域幅をリンクで利用できること。
共有サービスに関与するすべてのサーバーの役割が、データベースサーバーと同じデータセンター内に存在すること。これには、インデックス、クエリ、Excel Services の各役割が含まれます。
ファーム内のすべてのサーバーコンピュータが、同じネットワークセグメント上に存在すること。ルーターにおいてデータ層でのスイッチングが発生しないこと (実際には、物理層がサーバーを接続します)。ルーターやスイッチがあると、たとえそれらの間のネットワーク接続が非常に高速であっても、遅延が大きくなります。
Web サーバーにかかる負荷の種類がユーザー参照要求のサブセットの場合、Office SharePoint Server 2007 は Web サーバーとデータベースサーバーの間の若干の遅延を許容すること。一方、多数またはカスタムの Web パーツ、Stsadm コマンド、および検索クロールを含むページは、許容範囲が狭い傾向があります。
サーバーファーム内のサーバーが、タイムゾーンを越えないこと。サーバーファーム内のすべてのサーバーコンピュータは、同じタイムゾーンに同期する必要があります。

コンテンツクロールプロセスを最適化する

クロールプロセスをスケジュールや構成する方法は、パフォーマンスと信頼性に影響を与える場合があります。次のプロセスを最適化することで、WAN 経由のクロールを改善できます。

コンテンツソースのクロールを調整する。
クロール頻度を構成し、フルクロールと増分クロールを調整する。
クロール設定を構成する。

コンテンツソースのクロールを調整する

中央ファームが WAN リンク経由で地域ファームのコンテンツをクロールするグローバル環境では、スケジュールおよび管理できるコンテンツの単位はコンテンツソースなので、コンテンツソースを計画することが重要です。

以下のことが必要な場合は、検索用のコンテンツソースを追加します。

異なる種類のリポジトリをクロールする。
他のリポジトリとは異なるスケジュールで一部のリポジトリをクロールする。
クロールされるコンテンツの量を制限または増加させる。

これらの理由のいずれも、WAN 経由でのコンテンツクロールの最適化において考慮できます。少なくとも、地域ファームごとに異なるコンテンツソースを作成します。これにより、ファームのローカルなオフピーク時間帯および保守スケジュールに基づいて、各地域ファームでのクロールをスケジュールできます。

さらに、次の条件に基づいて、1 つの地域ファームに対して異なる複数のコンテンツソースを作成します。

クロールの頻度が高いソース (共同作業コンテンツなど) や低いソース (発行済みのコンテンツなど) で、異なるコンテンツソースを作成します。
定期的に発行されるコンテンツには、異なるコンテンツソースを作成します。たとえば、特定のサイトグループではコンテンツが金曜日にのみ更新されることがわかっている場合は、別のコンテンツソースを作成して、クロールのスケジュールとコンテンツの更新を同期させることができます。
地域ファームのオフピーク時間帯に WAN リンクを通してクロールできるコンテンツの量に基づいて、コンテンツソースを作成します。たとえば、大きなリポジトリを 1 週間に 1 回クロールすることが目標である場合は、夜間に無理なくクロールできる大きさの 5 ～ 7 個のコンテンツにリポジトリを分割し、毎週、クロールジョブを分散して実行できます。
Office SharePoint Server 2007 サイトの外部にあるコンテンツに対して、異なるコンテンツソースを作成します。Office SharePoint Server 2007 および Windows SharePoint Services 3.0 では、アクセス制御リスト (ACL) に対する更新など、変更のあったオブジェクトが変更ログに記録されます。変更ログを利用することで、変更されたコンテンツのみを増分クロールでき、コンテンツソースの再クロールに必要な時間が大幅に短縮されます。外部ソースに格納されているコンテンツに対して、増分クロールを行うことはできません。したがって、このようなコンテンツソースのクロールプロセスは、別に管理する必要があります。詳細については、「変更ログ」(https://go.microsoft.com/fwlink/?linkid=106007&clcid=0x411) を参照してください。

クロールとコンテンツソースの計画に関する詳細については、「コンテンツのクロールを計画する (Office SharePoint Server)」を参照してください。

クロール頻度を構成し、フルクロールと増分クロールを調整する

前のセクションで説明したように、異なるコンテンツソースを作成する主な理由は、異なるスケジュールでコンテンツをクロールできるようにすることです。これは、待機時間の長い WAN リンクを介してコンテンツをクロールする環境において特に重要です。地域ファームのクロールジョブのスケジュールを作成するときは、次の要素を考慮する必要があります。

地域ファームでの計画的なダウンタイムとピーク使用時間帯。
コンテンツが変更または更新される頻度。
WAN リンクの帯域幅の可用性と待機時間。WAN リンクを使用する他のプロセスも忘れずに考慮します。

Office SharePoint Server 2007 および Windows SharePoint Services 3.0 のコンテンツソースごとに、フルクロールを行うタイミング、およびそれとは別に増分クロールを行うタイミングを指定できます。増分クロールを実行するには、事前に特定のコンテンツソースに対するフルクロールを実行する必要があることに注意してください。まだクロールを行ったことがないコンテンツに対して増分クロールを選択すると、システムはフルクロールを実行します。

WAN 環境でのクロールスケジュールを計画するときは、次のベストプラクティスを考慮してください。

日時をずらしてクロールをスケジュールすることで、WAN リンクの使用時間を分散させ、WAN リンクが飽和するのを防ぎます。
フルクロールは必要なときにのみスケジュールします。フルクロールは増分クロールほど頻繁に行わないようにすることをお勧めします。
コンテンツをホストするサーバーが利用でき、サーバーのリソースに対する需要が低い時間に、各コンテンツソースの増分クロールをスケジュールします。
Service Pack の適用、データベースの復元など、Office SharePoint Server 2007 および Windows SharePoint Services 3.0 での管理上の変更の中には、定期的にスケジュールされている次回のクロール時にフルクロールを自動的にトリガするものがあります。フルクロールが必要な管理上の変更は、計画されているフルクロールのすぐ前に行うようにスケジュールします。たとえば、クロールルールの作成はスケジュールされている次回のフルクロールの直前に行い、余計なフルクロールを実行する必要がないようにすることをお勧めします。フルクロールが必要になる管理上の変更に関する詳細については、「コンテンツのクロールを計画する (Office SharePoint Server)」の「フルクロールを実行する理由」を参照してください。

重要

Microsoft Office Servers インフラストラクチャ更新プログラムを適用すると、その後は更新およびデータベースの復元によってフルクロールが自動的にトリガされなくなります。したがって、その後に更新の適用またはデータベースの復元を行うと、クロールルールで定義された定期スケジュールに基づいたクロールによる検索が続行されます。詳細については、「コンテンツのクロールを計画する (Office SharePoint Server)」を参照してください。

個別の地域サイトでのコンテンツのクロールに適用されるこれらのベストプラクティスに加えて、中央ファームの全体的なクロールスケジュールがインデックスサーバーに大きな負荷をかけないことを確認します。クロールの同時実行は、クロールを実行するインデックスサーバーの性能に応じて行います。インデックスサーバーおよびコンテンツをホストするサーバーのパフォーマンスによって、クロールを同時実行できる上限が決まります。クロールスケジュールに対する戦略は、各コンテンツソースの通常のクロール実行時間が把握されるにつれて改善することができます。

クロールとコンテンツソースの計画の詳細については、「コンテンツのクロールを計画する (Office SharePoint Server)」を参照してください。

クロール設定を構成する

WAN 環境に対するいくつかの固有のクロール設定を最適化して、クロールジョブの信頼性を高めることができます。以下の設定を使用できます。

検索のタイムアウト設定
クローラ影響ルール

検索のタイムアウト設定

ファーム管理者は、サーバーが他のサービスに接続するまでの待機時間、およびサーバーがコンテンツの要求を確認するまでの待機時間を指定できます。WAN リンク経由でクロールされるコンテンツソースを追加する場合は、リンクの全体的な待機時間に基づく予防措置としてタイムアウトの設定を大きくします。WAN リンク経由のコンテンツクロールの実際のパフォーマンスを基にして、いつでもタイムアウト設定を調整できます。

Office SharePoint Server Search サービスのタイムアウト設定を指定するには、次の手順を実行します。

タイムアウトの設定を指定する

[サーバーの全体管理] ページの [アプリケーション構成の管理] タブで、[検索] セクションの [Search サービスの管理] をクリックします。
[Search サービスの管理] ページの [ファームレベル検索の設定] セクションで、[ファームレベル検索の設定] をクリックします。
[ファームレベル検索の設定の管理] ページの [タイムアウト設定] セクションで、次の操作を行います。
- [接続時間 (秒数)] ボックスに、他のサービスへの接続中にサーバーを待機させる秒数を入力します。
- [要求確認にかかった時間 (秒数)] ボックスに、別のサービスがそのサービスへの接続要求を確認するまで、サーバーを待機させる秒数を入力します。
[OK] をクリックします。

クローラ影響ルール

クローラ影響ルールは、一度に要求およびクロールされるドキュメントの数を制御する手段を提供します。クローラ影響ルールを使用することで、管理者は WAN リンクに対するクロールジョブの影響を管理できます。

各クローラ影響ルールでは、単一の URL を指定するか、URL パスにワイルドカード文字を使用して URL のブロックにこのルールを適用することができます。次に、指定した URL に対して実行するページの同時要求の数を指定するか、一度にドキュメントを 1 つだけ要求し、次の要求まで指定した秒数だけ待機することを選択できます。

初期展開時には、WAN リンクをできるだけ効率よく使用する一方で、十分な量のコンテンツをその最新度を確保するために十分な頻度でクロールするよう、クローラ影響ルールを設定します。その後の運用段階では、経験とクロールログのデータに基づいてクローラ影響ルールを調整できます。

クローラ影響ルールを追加するには、次の手順を実行します。

クローラ影響ルールを追加する

[サーバーの全体管理] ページの [アプリケーション構成の管理] タブで、[検索] セクションの [Search サービスの管理] をクリックします。
[Search サービスの管理] ページの [ファームレベル検索の設定] セクションで、[クローラ影響ルール] をクリックします。
[クローラ影響ルール] ページの [ルールの追加] をクリックします。
[クローラ影響ルールの追加] ページの [サイト] セクションの [サイト] ボックスに、このクローラ影響ルールに関連付けるサイト名を入力します。

注意

URL を入力するときは、プロトコルを省略する必要があります。たとえば、http:// や file:// は含めません。
[要求頻度] セクションで、以下のオプションのどちらかを選択します。
- [指定した数のドキュメントを一度に要求し、次の要求まで待機しない]。このオプションを選択する場合は、[同時要求数] の一覧を使用して、この URL のクロール時にクローラで一度に要求するドキュメントの数を指定します。この URL のクロール時に Office SharePoint Services Search サービスで一度に要求する最大数を指定できます。
- [1 度に 1 つのドキュメントを要求し、次の要求まで指定した時間待機する]。この URL のクロール時に、次の要求を行うまでの時間 (秒単位) を指定できます。このオプションを選択すると、Office SharePoint Server Search サービスでは、サイトごとに要求を一度行うと、次の要求を行うまで指定された時間待機します。[待機時間 (秒数)] ボックスに、次の要求まで待機する時間を秒単位で入力します。次の要求までの時間は最小で 1 秒、最大で 1,000 秒です。
[OK] をクリックします。

クローラ影響ルールの詳細については、次の記事を参照してください。

クローラの影響を管理する (Office SharePoint Server 2007)
「検索環境のパフォーマンスと容量の要件を予測する」の「クローラ影響ルール」

WAN アクセラレータと他のサードパーティツール

ここでは、次のカテゴリのサードパーティソリューションを使用して WAN 環境を最適化するためのオプションについて説明します。

WAN アクセラレータ
オフロードとキャッシュデバイス
クライアントソリューション
データレプリケーション、マルチマスタ同期、および構成管理
マルチファーム管理性とレポート
バイトレベルまたはハードウェアベースのレプリケーション

環境は個々に異なるので、特定のパートナーソリューションをお勧めすることはしません。また、パートナーソリューションが案件に対処する方法はそれぞれ異なります。したがって、長所もソリューションごとに異なります。ユーザーの環境に固有のニーズおよびパートナーソリューションの相対的な長所に基づいて、各ソリューションを評価することが重要です。

Office SharePoint Server 2007 のソリューションを拡張または最適化するソリューションが、多くのパートナーから提供されています。最新のパートナーの一覧については、「Office System Solutions (英語)」(https://go.microsoft.com/fwlink/?linkid=108591&clcid=0x411) を参照してください。

WAN アクセラレータ

WAN アクセラレーションソリューションはかなり前からありました。最短パスアルゴリズムやパケット圧縮ツールは、何十年も前から提供されています。ここ何年かの間で最大の革新は、TCP/IP スタックおよびサーバーメッセージブロック (SMB) の最適化を対象としたものです。

ほとんどの WAN アクセラレータは、SharePoint 製品とテクノロジを実行するサーバーに隣接するデータセンターにインストールされているデバイスと、ブランチオフィスの別のデバイスの、ペアで動作します。2 つのデバイスは、キャッシュ、圧縮、差分、および固有の方法を使用して、2 つのデバイスの間で送信されるパケットを最適化することで、WAN トラフィックを最適化します。これらがインラインデバイスでも、キャッシュに対するアップグレードを含む単なるネットワーク装置でも、方法は似ています。パートナーソリューションによって、ネットワークスタック内での最適化対象のレイヤが異なります。

ネットワークアクセラレータを選択するときの 2 つの重要な考慮点は次のとおりです。

組織のセキュリティ要件。IPsec や HTTPS などの要件により、オプションが影響を受けます。
組織で使用されているアプリケーション。Microsoft Exchange Server およびファイル共有トラフィックも最適化するデバイスが必要な場合は、オプションが影響を受けます。

ソリューションの例としては、Cisco、Citrix、Packeteer、Riverbed、F5 などがあります。

オフロードとキャッシュデバイス

SharePoint 内のキャッシュ手法は不必要なバックエンドトラフィックを削減できますが、オフロードとキャッシュデバイスを提供するパートナーは、クライアントとサーバーの間の WAN 接続などのギャップの埋めることに役立ちます。

SharePoint サイトをインターネット経由でホストし、ネットワークトラフィックの最適化とサーバーをヒットする要求の量の削減が目標である場合は、オフロードとキャッシュデバイスが役に立ちます。インターネットに公開されるコンテンツをホストするプロセスの最適化のソリューションを、さまざまなパートナーが対象としています。この分野で採用される戦略としては、キャッシュおよびそれに関連する固有技術、さまざまなアルゴリズムでオフロードされた圧縮、ウォームアップとプリフェッチ、およびさまざまなショッピングカート手法などがあります。パートナーによっては、パブリックキオスク、世界規模のインターネットカフェにおけるコンピュータ、適切に接続されていない他のスリムデバイスなど、特定の種類のクライアントに安全で効率よくコンテンツを提供することに優れたものがあります。

また、インターネット分野には、廃棄されるパケットを減らすためのグローバルなキャッシュおよびネットワーク最適化ルーティング手法を提供するパートナーがいます。たとえば、クライアント要求の差分のみがサーバーに送信されるようにして、ネットワークトラフィックを最適化するソリューションがあります。この種のソリューションにより、WAN トラフィックは減少し、クライアントとサーバーの間または他の中間デバイス間のラウンドトリップ通信の数が減少することでページが返されるまでの時間が短縮されます。

Microsoft ISA と同様に、一部のソリューションは、情報にアクセスするためのゲートウェイとして、オフロードまたは委任された認証を提供します。これらのソリューションは、セキュリティのレイヤを追加します。複数の要件に対処するには、ファイアウォール、負荷分散、およびオフロードとキャッシュに対するインテリジェンスを提供する製品またはソリューションを探します。今後は、このような種類の機能がさらに統合されることが期待されます。

ソリューションの例としては、Cisco、F5、Inktomi、Microsoft ISA Server、Microsoft Internet Application Gateway などがあります。

クライアントソリューション

ネットワークとサーバーインフラストラクチャではなく、クライアント環境の最適化に注目しているパートナーもいます。プリフェッチ、バックグラウンド同期、圧縮、広告ブロッカ、イメージフィルタなどの手法を使用すると、インターネットでのコンテンツ取得のパフォーマンスが大幅に向上する可能性があります。テキストが主要な対象でイメージは必要ない場合は、特に有効です。

複数のクライアントアプリケーションが、SharePoint サイトとの自動同期に対応しています。最初にクライアントがサイトと同期した後は、クライアントアプリケーションが自動的に、バックグラウンドで、またはクライアントがオンラインのときに、サイトのコンテンツをクライアントコンピュータ上にキャッシュします。たとえば、ユーザーがドキュメントをクリックしたときには、ドキュメントは既にローカルに利用できる状態になっており、ユーザーは WAN リンクの影響を受けません。同様に、ユーザーがドキュメントを追加または更新すると、クライアントアプリケーションがオンラインサイトとの変更の同期を処理します。これらのクライアントアプリケーションは、通常、発生する競合を管理し、競合の解決方法をユーザーが決定できるようにします。

クライアントによっては、他のクライアントよりも効率よくこの環境を処理します。一部のクライアントはファイルのみをサポートします。一部のアプリケーションは、リストとファイルの両方をサポートします。オフライン Wiki はおそらく見つかりませんが、ほとんどのリストをローカルまたはオフラインで利用する RSS リーダーなら見つかります。Office Outlook 2007 は、RSS リーダーを備えた RSS を使用して SharePoint ブログまたはリストをオフラインで使用でき、さらにドキュメントライブラリとの同期もできるクライアントの一例です。また、Office Groove 2007 は、使いやすいオフライン環境を提供し、WAN 経由でのピアツーピア共同作業とファイル圧縮の機能を追加します。Microsoft クライアントソリューションの詳細については、「Office Outlook 2007 および Office Groove ソフトウェアを使用して Office SharePoint Server グローバルソリューションを拡張する」を参照してください。

この分野のパートナーは、パフォーマンスが WAN リンクの影響を受けたり、クライアントが頻繁にオフラインになるようなユーザー環境の最適化に着目しています。キャッシュ (ローカルコピー)、圧縮、および同期の実行をバックグラウンドに移すことによって、サーバーとの LAN 接続のような環境を実現できます。ユーザーにクライアントアプリケーションを提供する場合は、ユーザーができる限り効率よく作業できるように、適切なトレーニングを実施する必要があります。

パートナー : Colligo。Microsoft : Microsoft Office Outlook 2007、Office Groove 2007。

データレプリケーション、マルチマスタ同期、および構成管理

2 つのオフィス間の低速 WAN リンクや、マルチマスタ要件を含む障害復旧など、理由はさまざまですが、展開計画ではレプリケーションが必要になることがよくあります。SQL Server 2005 では、障害復旧またはサイトのフェールオーバー用に、ログ配布およびデータベースミラーリングの機能が提供されています。ただし、2 つの異なるサーバーファームがあり、両方が読み取り/書き込みアクセスを提供する必要がある場合は、パートナーからソリューションが提供されています。

一部のパートナーソリューションは、WAN アクセラレータに似たサーバーキャッシュを備えています。WAN リンクで障害が発生した場合は、ソリューションがリモートサイトにあるキャッシュから継続してコンテンツを提供します。サイトを長時間の切断後に接続したときのデータの同期に優れているパートナーもいます。たとえば、航海の後でドックに到着した船は、セントラルサイトと同期できます。

パートナーによっては、SharePoint 製品とテクノロジのインターフェイスを拡張し、Web アプリケーション、サイトコレクション、またはリストのペアに対するレプリケーションを構成するものがあります。

注意

製品チームは、Office SharePoint Server 2007 の発行機能を WAN 環境ではまだテストしていません。発行機能は、中央ファームから読み取り専用環境へのコンテンツの発行において役に立つ可能性があります。ただし、テスト結果がないので、このシナリオでの具体的なガイダンスは提供できません。

パートナーソリューションとしては、Syntergy、WinApp Technologies、Casahl、Infonic などがあります。

マルチファーム管理性とレポート

複数のサーバーファームを含むグローバルな展開では、ファーム間およびサイト間の設定の管理が課題になります。複数のパートナーから、構成設定、アクセス許可、効果的なユーザー権限、およびマスタページやコンテンツタイプなどのコンテンツ要素の管理を簡略化するツールが提供されています。環境に複数のサーバーファームを展開する場合は、複数のファームと多数のサイトの管理に役立つパートナーツールを検討してください。

一部のパートナーは、複数のファームおよび環境に関係する設定の構成を支援することに重点を置いています。「SharePoint Cross Site Configurator (英語)」(https://go.microsoft.com/fwlink/?linkid=108592&clcid=0x411) は、Web アプリケーション間で整合性のとれた監査、有効期間、マスタページ、およびコンテンツタイプを構成するために Microsoft が設計したツールの例です。

パートナーソリューションとしては、Quest Software、echoTechnologies、IDevFactory、AvePoint、CorasWorks、Barracuda Tools、CommVault、Symantec などがあります。

バイトレベルまたはハードウェアベースのレプリケーション

パートナーが提供するハードウェアベースまたはバイトレベルのレプリケーションを利用すると、データセンター間でのフェールオーバーおよび環境の同期が非常に簡単になります。ストレージエリアネットワーク (SAN) のような共有ディスクを導入すると、その共有ディスクが障害点になる可能性があります。ハードウェアベンダは、さまざまな方法を使用して、冗長チャネル、冗長ファイバ、冗長ディスク、およびさまざまなアレイ構成を提供しています。ソリューションにより、提供されるフォールトトレランスのレベルが異なります。

ハードウェアが障害の発生源になる可能性を除去する必要がある場合は、Microsoft Cluster Services (MSCS) を検討してください。MSCS はハードウェアベースのフォールトトレランスを提供します。SQL ログ配布、SQL ミラーリングなど、ソフトウェアベースのフェールオーバーソリューションもハードウェアのフォールトトレランスを提供しますが、SharePoint 製品とテクノロジと共に使用した場合には自動的なフェールオーバーは行われません。

場合によっては、スタックの下位レベルでのレプリケーションを提供するソリューションを実装することで、特定のビジネスニーズに対処できます。プライマリ環境のクローンまたはミラーを作成するバイトレベルのレプリケーションも、フェールオーバー先となるセカンダリ環境を作成できます。連続したバイトレベルのレプリケーションは、自動または手動のフェールオーバーのための手段を提供できます。

これらのレプリケーションソリューションを評価するときの重要な注意点は、サーバー名、Web アプリケーション名、およびアカウントが構成データベースにハードコードされるかどうかを確認することです。つまり、異なるサーバーに異なる名前でレプリケートされるサービスは動作しません。サーバー名がレプリケート先の環境でもプライマリ環境と同じ場合は、この種のソリューションが動作できます。どのようなソリューションでも、アプリケーションが認識する範囲外でのレプリケーションをツールが提供する場合は、ツールがフェールオーバー環境で動作することをテストする必要があります。

パートナーソリューションとしては、Neverfail や Double-take があります。

SAN ベースのレプリケーションのようにハードウェアに組み込まれているソリューションとしては、HP、EMC Centera、Hitachi Data Systems などがあります。

ダウンロードの時間が短くなるようにページを設計する

ネットワーク容量が限られた環境では、ページを簡素化し、できるだけ小さく、そして応答性をよくする必要があります。そのためにはさまざまな方法がありますが、ほとんどは SharePoint 製品とテクノロジに固有のものではありません。任意の Web サイトで使用できる一般的な方法については、ここでは詳しく説明しません。ここでは、SharePoint 製品とテクノロジに含まれる機能、ページに含まれる機能、および SharePoint サイトへの最初のアクセスを高速化する方法に焦点を当てて説明します。

ページの要素

SharePoint サイトのページは、次の図で示すように、複数の固有の要素で構成されています。

コントロールが重なった [SharePoint サイト] ページ

ページが表示されるときには、マスタページ、レイアウトページ、およびページのコンテンツが結合されます。ページのコンテンツには、ページの各フィールドの値が含まれますが、テーマ、スタイルシート、画像、ナビゲーションなど、それ以外の要素も多く含まれます。次の表では、SharePoint サイトからの 1 つのページに含まれるファイルとストリームの例を示します。この例は、共同作業ポータルサイトの既定のホームページに初めてアクセスしたときに行われたすべての HTTP 要求を取得したものです。

URL	サイズ (バイト)
http://myServer/_layouts/images/topnavhover.gif	96
http://myServer/Pages/Default.aspx	1656
http://myServer/Pages/Default.aspx	1539
http://myServer/Pages/Default.aspx	66084
http://myServer/_layouts/1033/styles/controls.css?rev=EhwiQKSLiI%2F4dGDs6DyUdQ%3D%3D	1448
http://myServer/_layouts/1033/styles/HtmlEditorCustomStyles.css?rev=8SKxtNx33FmoDhbbfB27UA%3D%3D	642
http://myServer/_layouts/1033/styles/HtmlEditorTableFormats.css?rev=guYGdUBUxQit03E2jhSdvA%3D%3D	1317
http://myServer/_layouts/1033/styles/core.css?rev=5msmprmeONfN6lJ3wtbAlA%3D%3D	13596
http://myServer/_layouts/1033/init.js?rev=VhAxGc3rkK79RM90tibDzw%3D%3D	15732
http://myServer/_layouts/1033/core.js?rev=F8pbQQxa4zefcW%2BW9E5g8w%3D%3D	54367
http://myServer/_layouts/portal.js?rev=INhSs9mWTnUTqdwwIXYMaQ%3D%3D	954
http://myServer/_layouts/1033/ie55up.js?rev=Ni7%2Fj2ZV%2FzCvd09XYSSWvA%3D%3D	20508
http://myServer/_layouts/1033/search.js?rev=yqBjpvg%2Foi3KG5XVf%2FStmA%3D%3D	5092
http://myServer/_layouts/1033/EditingMenu.js?rev=eh0f0CwzvHQ7Ii0JvdsIjQ%3D%3D	2735
http://myServer/WebResource.axd?d=__WrA1TRLicJgwGEmYKqSA2&t=633214754549731034	5383
http://myServer/WebResource.axd?d=h_u9v0Coj_eDqsvEkDrdtw2&t=633214754549731034	8258
http://myServer/_layouts/images/blank.gif	43
http://myServer/_layouts/images/helpicon.gif	1025
http://myServer/_layouts/images/Menu1.gif	68
http://myServer/_layouts/images/titlegraphic.gif	1299
http://myServer/_layouts/images/gosearch.gif	19933
http://myServer/WebResource.axd?d=puevA5kEAx44yxozBd-hspPZ9eA51Rh9u95VwVGLFCc1&t=633214754549731034	224
http://myServer/WebResource.axd?d=wyTuS1folQ6wX2Tc_7NOOaeElHHqL6rtdeAeRRUR36s1&t=633214754549731034	218
http://myServer/_layouts/images/whitearrow.gif	68
http://myServer/_layouts/images/recycbin.gif	1004
http://myServer/PublishingImages/newsarticleimage.jpg	10710
http://myServer/_layouts/images/icongo01.gif	1171
http://myServer/_layouts/images/menudark.gif	68
http://myServer/_layouts/images/topnavhover.gif	96

次のことに注意してください。

ページをダウンロードするには、全部で 29 個の要求が必要でした。
ページの合計サイズは、235 KB でした。
この値は、ページを初めて読み込むときのものです。要求のほとんどすべてのアイテムには、1 年間はアイテムを再び読み込まないようブラウザに指示するキャッシュディレクティブが指定されています。2 回目以降のページ読み込みでは、生成される要求は 3 つだけです。もちろん、そのうちの 2 つは発生する NTLM ネゴシエーションの一部なので、実際にダウンロードされるのは、ページの HTML だけです。
既定の IIS 圧縮レベルである 0 が使用されました。これは、可能な最小限の圧縮です。さらに圧縮すると、ダウンロードサイズはいっそう小さくなります。
読み込まれたファイルタイプ別では、次のようになりました。
- 4 個の .axd リソース要求
- 4 個の .css リソース要求
- 12 個の画像リソース要求
- 6 個の .js リソース要求 (このうちのいくつかは重複していました)
- default.aspx に対する 3 個のページリソース要求 (そのうちの 2 つは NTLM ネゴシエーションの一部でした)

これらのファイルタイプのほとんどは何も問題ありませんが, .axd リソースタイプだけはそうではない可能性があります。.axd リソースは、ASP.NET バージョン 2.0 での新機能の一部です。開発者は、スクリプトファイル、スタイルシートなど、リソースをコントロールに追加できます。コントロールでは、ClientScript クラスを使用して、GetWebResourceUrl という名前のメソッドを組み込みます。コントロールは、実行時に表示されるときに、リソースの URL を動的に生成します。リソース自体はコンパイルされてコントロールのアセンブリに格納されているので、この方法を使用すると、Web サーバーに別のファイルとして格納されている場合と同様に、リソースをアセンブリから取り出してクライアントにストリーミングできます。

ページで使用されるリソース要求を知っておくと、最適化を適用する場所と方法を理解するのに役立ちます。この種の情報は、さまざまなツールや手法を使用して評価できます。この記事では、Fiddler (英語) というフリーウェアのツールを使用しました。Fiddler は、クライアントワークステーション上で実行でき、ページに対して行われるすべての HTTP 要求を追跡します。その後は、次の図に示すような列挙形式で結果を表示します。

SharePoint サイトの Fiddler 結果

サイトに最適化の変更を行った後、Fiddler を使用してテストします。要求されているアイテム、キャッシュされているアイテム、および各アイテムのサイズを最も正確に知るには、次のようにします。

ブラウザの一時ファイルをすべて削除します。
Fiddler を起動します。
ページを要求します。

注意

リンクをクリックしてページを要求するようにします。更新ボタンをクリックするだけでは、システムは自動的にアイテムを再び要求するので、行った最適化の変更が正確に反映されません。

ページのダウンロードを最適化する

ページの構成を理解した後は、さまざまな方法を使用してページのダウンロード環境を最適化できます。一般的な目標は、クライアントコンピュータとサーバーコンピュータの間のラウンドトリップの数を最小限にして、ネットワークで送信されるデータの量を削減することです。このガイダンスでは、SharePoint 製品とテクノロジのさまざまな実装に広範に適用できる推奨事項を示します。

これらの推奨事項を検討する場合と、ユーザーが開発する他のカスタム最適化を検討する場合では、注意する必要のある重要な違いがあります。ページの最適化手法は、最初のページ要求と、2 回目以降のページ要求の 2 つのカテゴリに分類できます。最初のページ要求の最適化は、ページが初めて要求されるときに実施される種類の最適化であり、2 回目以降のページ要求には必ずしも影響を及ぼしません。2 回目以降のページ要求を最適化すると、ユーザーがそのページを要求するのが初めての場合でも、50 回目の場合でも、ユーザーの操作環境が向上します。重要なことは、失われる機能と得られるメリットのバランスを考慮することです。ユーザーがサイトに初めてアクセスしたときにしかメリットが実現されないのであれば、機能を減らしてまで最適化を行う価値はありません。

BLOB キャッシュ

バイナリラージオブジェクト (BLOB) キャッシュについては、後でさらに詳しく説明します。要約すると、BLOB キャッシュは、SharePoint 製品とテクノロジに格納されるページ上のアイテムに対してキャッシュディレクティブを適用するために使用できます。キャッシュディレクティブが含まれていると、ブラウザは、キャッシュされているアイテムの有効期限が切れるまで、アイテムを再びダウンロードすることはありません。前のホームページの例で示されているように、共同作業ポータルの既定のホームページに含まれるほとんどすべてのアイテムには、キャッシュディレクティブが指定されています。このため、2 回目以降のページヒットではアイテムが要求されませんでした。BLOB キャッシュの設定と構成の詳細については、この後の「WAN 環境でのキャッシュを最適化する」を参照してください。

IIS 圧縮

IIS 圧縮についても、この後の「WAN 環境でのキャッシュを最適化する」で詳しく説明します。ただし、既に説明したように、既定の設定では圧縮レベル 0 が使用されます。Web サーバーの CPU に対する影響を最小にしながら、最善の圧縮効果が得られるまで、さまざまな圧縮設定レベルを調べる必要があります。ほとんどすべての場合において、0 より大きい圧縮レベルを使用できます。ただし、重要なこととして, .axd や .aspx ファイルなど、動的なファイルに対してのみ圧縮レベルが適用されることに留意してください。

64 ビットハードウェア

ファームでのハードウェアの選択は、要求の待機時間にも影響を与える可能性があります。32 ビットシステムには、アプリケーションごとに 2 GB の RAM という制限があります。アプリケーションのサポートを 3 GB の RAM にまで拡張できますが、SharePoint 製品とテクノロジは /3GB スイッチの使用をサポートしていません。メモリが少ない状況は、要求の待機時間に次のような悪影響を及ぼす可能性があります。

メモリの量が制約されるようになると、SharePoint のアプリケーションプールがリサイクルされる場合があります。それにより、ASP.NET のアプリケーションドメインも強制的にリサイクルされ、ユーザー要求への応答で長い遅延が発生する可能性があります。
メモリ不足エラーにより、BLOB キャッシュがコンテンツの提供を停止する可能性があります。

64 ビットハードウェアを使用することで、十分な RAM を割り当てて使用できるようになり、このようなエラーを防止できます。

Web ガーデンの設定

Web ガーデンの設定によっても、意図せずに、BLOB キャッシュで一貫性のない動作が発生する可能性があります。キャッシュの管理に必要なロックを取得できるのは 1 つのプロセスだけなので、キャッシュの使用が成功するかどうかは、どのスレッドが要求を処理するかに依存します。BLOB キャッシュのロックを取得してない Web ガーデンが要求を処理すると、応答で送信されるコンテンツには、キャッシュディレクティブが関連付けられません。そのため、要求の数とネットワーク上を送信されるデータの量が、どちらも増加します。したがって、BLOB キャッシュを使用する場合は、Web ガーデンを使用しないようにする必要があります。

ページ上のセキュリティ保護されたアイテムを最小限に抑える

ユーザーが SharePoint 製品とテクノロジの認証を受けるときは、2 つのことが行われます。最初に、システムは資格情報を検証して、ユーザーの身元を特定します。次に、役割プロバイダが、ユーザーが属している SharePoint グループの一覧を列挙します。役割プロバイダは、ページが要求されるたびに再び呼び出されて、ユーザーが属しているすべてのグループを列挙します。

ただし、このグループメンバシップの呼び出しは、1 つのページで何回も発生する場合があります。たとえば、既定の共同作業ポータルサイトのテンプレートページでは、ユーザーがホームページにアクセスすると、ページ自体について 1 回とページ上の画像について 1 回で合わせて 2 回、役割プロバイダを呼び出す必要があります。SharePoint ライブラリに格納されていてページ上にある画像ごとに、役割プロバイダが強制的に呼び出されて、アクセス許可が検証されます。これは、すべての画像が同じ画像ライブラリに格納されていても同じです。この検証は、画像がページのフィールドとして追加されているかどうか (つまり、ページのコンテンツの一部であるかどうか)、またはサイトのマスタページに追加されているかどうかにかかわらず、発生します。

帯域幅に制約のある環境または待機時間の長い環境用に作成するサイトは、ページで使用する画像の数が最小限になるように設計する必要があります。多くのサイトは、マスタページの一部として複数の画像を使用し、異なる視覚効果を作り出しています。セキュリティチェックの数が増えると待機時間が長くなるので、このような環境で使用するサイトでは、使用する画像をできる限り少なくする必要があります。

画像の数とサイズを最小限に抑える

前のセクションで説明したように、サイトで使用する画像の数を最小限に抑える必要があります。これに役立つ方法として、複数の画像を 1 つのファイルに埋め込み、ページで個別の画像を参照することができます。ファイルのダウンロードサイズが小さくなるだけでなく、ファイルが少なくなるとネットワークトラフィックも減少します。この方法を使用するとページの作成は複雑になりますが、すべてのラウンドトリップとファイルサイズが重要であるような状況では、パフォーマンスの向上に役立つ有効な手段であることがわかります。次の図は、複数の画像を含む 1 つの画像ファイルの例です。

一列に並んだ 6 つのアイコンイメージ

次の図は、この画像が後で変更されて表に個別の写真として表示されるようすを示しています。

表で示された 6 つのアイコンイメージ

画像の操作は、すべてスタイルシートクラスを使用して行っています。表の各セルの div 要素と img 要素では、主に 2 つのクラスが使用されています。これらのクラスは次のようになります。

.cluster {

height:50px;

position:relative;

width:50px;

}

.cluster img {

position:absolute;

}

各画像には、画像の識別子 (ID) に基づいて、クラスが関連付けられています。そのスタイルによって画像がクリッピングされ、クラスタ内での初期画像からのオフセットが定義されます。そのようなクラスを次に示します。

#person {

border:none;

clip:rect(0, 49, 49, 0);

}

#keys {

clip:rect(0, 99, 49, 50);

left:-50px;

}

#people {

clip: rect(0, 149, 49, 100);

left:-100px;

}

#lock {

clip:rect(0, 199, 49, 150);

left:-150px;

}

#phone {

clip:rect(0,249, 49, 200);

left:-200px;

}

#question {

clip:rect(0, 299, 49, 250);

left:-250px;

}

表の HTML には、次のように、div タグおよび img タグと適切な ID 値およびクラス名が含まれます。

<table border="1">

<tr>

<td><div class="cluster"><img id="person" src="Icons50x50.gif" width="300" height="50"/></div></td>

<td><div class="cluster"><img id="keys" src="Icons50x50.gif" width="300" height="50"/></div></td>

<td><div class="cluster"><img id="people" src="Icons50x50.gif" width="300" height="50"/></div></td>

</tr>

<tr>

<td><div class="cluster"><img id="lock" src="Icons50x50.gif" width="300" height="50"/></div></td>

<td><div class="cluster"><img id="phone" src="Icons50x50.gif" width="300" height="50"/></div></td>

<td><div class="cluster"><img id="question" src="Icons50x50.gif" width="300" height="50"/></div></td>

</tr>

</table>

Microsoft Passport Network および Microsoft Office Outlook Web Access (OWA) を含む複数の Microsoft Web プロパティおよび製品が、この技術を使用するようになっています。MSN のチームはいくつかのパフォーマンステストを実施して、変更の影響を分析し、最初のページの読み込み時間が 50 ～ 75% 向上したことを確認しました。

Microsoft Office SharePoint Designer 2007 でページを作成する場合は、考慮する必要のある重要なポイントがあります。Office SharePoint Designer 2007 で新しいページを作成すると、次の XHTML スキーママークアップがページに自動的に追加されます。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

It then adds this namespace to the HTML element:

<html xmlns="http://www.w3.org/1999/xhtml">

このスキーマを使用すると、画像が正しく整列されません。画像を意図したとおりに表示するには、xmlns 属性を HTML タグから削除する必要があります。

core.js のダウンロードを遅らせる

Office SharePoint Server 2007 に含まれるメインのクライアントスクリプトファイルは core.js という名前です。これは、圧縮されていない状態で約 257 KB、圧縮された状態で約 54 KB という、最大のスクリプトファイルです。ある種の状況では、core.js のダウンロードを遅らせてもかまいません。そのようにすると、core.js ファイルのダウンロードはページがブラウザで開かれるまで開始しないので、ページの表示が速くなります。これにより、ユーザーがページを表示してコンテンツを読み始めるまでの時間が短縮されます。この方法は、匿名ユーザーのインターネットシナリオにおいて最も有効です。逆に、認証を受けたユーザーの場合は、[サイトの操作] メニューのような機能や UI 要素のためのページの読み込み時に、core.js がダウンロードされる必要があります。

次の手順を使用して、この手法を実装できます。

core.js を使用しないカスタムレイアウトページを作成します。このレイアウトページをホームページと共に使用して、サイトの最初の訪問者が core.js の即時ダウンロードによって待たされることがないようにします。新しいレイアウトページは、既存のホームページと互換性を持つ必要があるので、現在使用されているレイアウトページと同じコンテンツタイプを関連付けられる必要があります。

注意

既定では、共同作業ポータルサイトには、ウェルカムページコンテンツタイプが指定されています。
タグ <SharePointWebControls:ScriptLink runat="server"/> をページに追加します。このタグは、システムに対し、参照されない限り core.js を使用しないように指示します。
認証済みのユーザーを検査するカスタムコントロールを作成します。このコントロールは非常に簡単なもので、基本的には次のコード (C# を使用しています) を含みます。
```
if (HttpContext.Current.Request.IsAuthenticated)   
    Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);
```
各 Web サーバーにおいて、グローバルアセンブリキャッシュ (GAC) にコントロールを格納し、コントロールに対する SafeControl エントリを、コントロールが使用される Web アプリケーションの Web.config ファイルに追加します。
手順 1. で作成したカスタムレイアウトページに、カスタムコントロールを追加します。

レイアウトページに IFRAME を追加します。これは、次の内容のページを参照しています。

<body>
<SharePoint:ScriptLink name="core.js" runat="server" />
<script language="javascript">
 DisableRefreshOnFocus();
</script>
</body>

カスタムレイアウトページをチェックインして発行します。
サイトのホームページのベースを新しいレイアウトページにします。

以上の手順を実行した後、サイトのホームページをテストして、その動作を検証します。初めての匿名ユーザーに対しては core.js への参照がページソースに表示されませんが、最終的にはブラウザキャッシュに格納されます。

さらに、この手法を使用する前に、次のことを考慮します。

サイトマスタページとシステムマスタページは異なっている必要があります。そうでないと、_layouts 内のすべてのページが正しく動作しません。
動作するために読み込み時に core.js を必要とするコントロールがマスタページに含まれないことを確認します。
core.js を読み込んだり参照したりする ScriptLink コントロールがマスタページに存在しないことを確認します。

詳細およびサンプルコードについては、「Microsoft Enterprise Content Management (ECM) Team Blog (英語)」(https://go.microsoft.com/fwlink/?linkid=106008&clcid=0x411) を参照してください。

リストビューページを最適化する

Microsoft Services チームは、リストビューページ表示時のパフォーマンスを定量化して改善する作業を行ってきました。リストビューページは、各リストおよびライブラリがコンテンツを表示できるようにするために使用する AllItems.aspx ページです。このページの表示時間は、ビューに表示する列の数とその書式によって大きく異なる場合があります。たとえば、表示オプションを使用し、プレゼンスアイコンを有効にすると、表示時間に大きく影響することがあります。折りたたまれたグループは展開されたグループより表示に長い時間がかかり、まったくグループ化しない場合と比べるとどちらの場合も時間がかかりました。

この種の微妙な差異があるので、リストビューページでのビューの作成方法を慎重に検討することが重要です。ネットワークリンクが低速の場合は特に重要になります。多くのデータを含むリストを使用するときは、すべてのビューを注意深く調節することが重要で、既定のビューについては特に重要です。一般には、次のようにするとリストビューの表示時間を短縮できます。

表示する列を少なくします。
プレゼンス情報を含む列を除外します。
アイテムの詳細の表示にはリンク (ただし編集メニューのないもの) を使用します。

次の表では、ビューの表示に必要な時間を短縮するカスタマイズについて説明します。

項目	説明
ビューの種類	標準ビューではなくデータシートビューとしてビューを作成します。
ビュー : アイテムの制限	何でも 1,000 を超えると表示が遅くなります。低速の接続を使用する場合は、実験を行って、一度に表示するデータの量と、すべてのデータを表示するために必要なラウンドトリップの回数の間の適正なバランスを見つけることが重要です。一度に表示する行数を増やすほどラウンドトリップは減りますが、ページは大きくなります。
ビュー : フィルタ	[今日] および [自分] を使用して、最新度または割り当てでアイテムをフィルタ処理します。[状態] フィールドを使用して、既定ビューではアクティブなアイテムのみを表示します。
ビュー : 列	必要最小限の列を使用します。既定のビューは少数の列で作成して概要を表示し、その後でドリルダウンできるようにします。

次の表では、ビューの表示に必要な時間が長くなるカスタマイズについて説明します。1 列増えるごとに、表示時間がわずかに長くなります。1,000 アイテムのリストの場合、高速のネットワーク接続を使用すると、1 列につき最高で 0.5 秒増加します。表で示されているように、列によってはさらに長くなります。

項目	説明
グループ化	グループ化を使用すると HTML および JScript が増え、大きいリストの表示が遅くなります。既定ですべてのグループを折りたたむようにすると、ブラウザのオブジェクトモデルでの操作が増えるので、実際には表示時間がさらに長くなります。
列 : 編集メニューでアイテムにリンクされたタイトル	[編集メニュー付きのアイテムにリンク] オプションを指定すると、最も時間がかかります。似てはいますが、[アイテムへのリンク] オプションを指定した場合は、表示時間は顕著には増加しません。
列 : プレゼンスでのユーザーの検索	プレゼンスでのユーザー検索フィールドを追加すると、プレゼンスメニューを開くための HTML がリンクごとに追加されます。さらに、プレゼンスが利用できるかどうかを判定するために帯域幅も使用されます。

次の表では、ビューの表示に必要な時間に与える影響が比較的小さいカスタマイズについて説明します。

項目	説明
並べ替え、集計	複数の並べ替えおよび集計を適用すると、認識できる程度に表示時間が増加しますが、個々については、通常、1,000 アイテムのリストで 1 秒未満です。

WAN 環境でのキャッシュを最適化する

Office SharePoint Server 2007 には複数のキャッシュオプションがあります。そのうちのいくつかは、表示パイプラインでのスループット、つまり要求がサーバーで受信されてからクライアントコンピュータに戻すストリーミングを応答が開始するまでに要する時間の向上を目的としたものです。これはサイトの全体的なパフォーマンスにとって重要な側面ですが、ここでは次のことに関係する場合のキャッシュに焦点を当てます。

クライアントキャッシュでのサーバー構成の役割。
サーバーからクライアントにネットワーク経由で送信されるアイテムのサイズの制御。

BLOB キャッシュ

BLOB キャッシュは、Office SharePoint Server 2007 の発行機能でのみ使用できるメカニズムです。このメカニズムによって Office SharePoint Server 2007 は、共同作業ポータルサイトテンプレートに基づく企業ポータルサイトとしても、発行ポータルサイトテンプレートに基づくインターネット接続サイトとしても、理想的な候補となります。BLOB キャッシュを使用すると、発行サイトリストから提供されるページライブラリやサイトコレクションイメージなどのアイテムと関連付けられたキャッシュディレクティブを構成できます。クライアントコンピュータのブラウザは、キャッシュディレクティブを検出すると、取得する対象のアイテムがローカルに保存できること、したがってキャッシュディレクティブの有効期限が切れるまでは再び要求する必要がないことを認識します。それによりネットワーク経由で要求および送信されるアイテムの数が減少するので、地理的に分散した環境では非常に重要です。

Office SharePoint Server 2007 で BLOB キャッシュを有効にすると、2 つの異なる処理が行われます。第 1 に、キャッシュ可能なアイテムが要求されるたびに、Office SharePoint Server 2007 は、要求を受け取った Web サーバーのハードディスクドライブを検索して、コピーがローカルに存在するかどうかを調べます。存在する場合、ファイルはローカルディスクからユーザーに直接ストリーミングされます。ローカルディスクにまだ存在しない場合は、アイテムが格納されている SQL データベースからアイテムのコピーが作成され、アイテムは要求元のユーザーに送信されます。それ以降、アイテムのキャッシュ可能値が有効期限切れを示すまでは、そのアイテムに対するすべての要求には、Web サーバーで直接対応できます。その結果、データベースサーバーで発生する競合が減少し、サーバーファームのパフォーマンスが向上します。

第 2 に、アイテムがクライアントに送信されるときにキャッシュ可能ヘッダーがアイテムに付加されます。このヘッダーは、ブラウザに対し、アイテムをキャッシュしておく必要のある期間を指示します。たとえば、ある写真のキャッシュ可能値が 3 日の場合、それから 3 日以内に再び写真が要求されると、ブラウザはローカルキャッシュに存在する画像のコピーを使用します。サーバーに再度画像を要求することはありません。

サイトをテストして、キャッシュされているアイテムおよびそのキャッシュ方法を確認するには、Fiddler (英語) (http://www.fiddlertool.com) を使用できます。次のスクリーンショットは、発行に使用されている簡単な SharePoint サイトを Fiddler でキャプチャしたものです。このサイトは、既定の共同作業ポータルサイトテンプレートを使用して作成されています。ページには若干のテキストコンテンツが追加され、マスタページにはいくつかの画像が追加されています。

Fiddler ツールの結果

Fiddler アプリケーションには、いくつかの重要な情報が含まれています。

左側の [#] 列では、ページを表示するためにブラウザからサーバーに対して全部で 44 個の HTTP 要求が行われたことが示されています。
[Result] 列では、アイテムの要求から返された HTTP 結果コードが示されています。200 という結果は、アイテムが正常に取得されたことを意味します。
[URL] 列では、要求された特定のアイテムが示されています。
[Body] 列では、各アイテムのサイズが示されています。
[Caching] 列では、各アイテムに関連付けられていたキャッシュディレクティブが示されています。[Caching] 列のデータは、複数のアイテムにキャッシュディレクティブが関連付けられていることを示しています。つまり、0 より大きい max-age 属性が設定されています。キャッシュディレクティブは秒単位で表されます。つまり、例で示されているページの場合、複数のアイテムに 365 日間 (1 分は 60 秒、1 時間は 60 分、1 日は 24 時間なので = 60x60x24 = 86,400x365 = 31,536,000) のキャッシュが構成されています。

このキャッシュディレクティブが指定されたアイテムはすべて _layouts ディレクトリにあることに注意してください。これらのアイテムにキャッシュ設定がある理由は、IIS での _layouts/images 仮想ディレクトリの構成方法によるものです。新しい Web アプリケーションを作成すると、Office SharePoint Server 2007 は、Web サーバーの物理ディスク上のフォルダにマップする複数の仮想ディレクトリを自動的に作成します。_layouts/images 仮想ディレクトリを作成すると、ディレクトリ全体に適用されるキャッシュディレクティブを追加します。次のスクリーンショットは、IIS マネージャスナップインでのディレクトリの構成を示しています。

画像フォルダの IIS Manager プロパティ

これらのアイテムにはすべて 0 以外のキャッシュディレクティブが関連付けられているので、次回のページ要求では、ブラウザは、再びサーバーにアイテムを要求するのではなく、ローカルブラウザキャッシュに存在するアイテムのコピーを使用します。次のスクリーンショットは、ページが 2 回目に要求されたときの Fiddler のスナップショットです。

Fiddler ツールの結果

Fiddler のデータが示すように、要求されたアイテムの数は、44 から 11 に大きく減っています。注意する必要のある重要なことは、行われる要求の数は、ページの要求方法によって異なる場合があるということです。ブラウザの更新ボタンを使用すると、アイテムのローカルキャッシュバージョンが存在するかどうかに関係なく、すべてのアイテムが再び要求されることになります。そうではなく、リンクまたはショートカットを使用してページに移動することでページが要求された場合は、キャッシュされていないアイテムだけが要求されます。

Fiddler データで示されているもう 1 つのこととして、ブラウザはローカルキャッシュに既に存在するマスタページ上の他の画像をサーバーに要求しています。304 という応答コードがこのことを示しています。つまり、ブラウザはアイテムを条件付きで要求しています。304 という応答は、サーバー上のバージョンは、クライアント上のバージョンから変更されていないので、再びダウンロードする必要はないことを意味します。ネットワーク経由でファイルがダウンロードされることはありませんが、ローカルコピーが最新かどうかを判別するために、サーバーへのラウンドトリップが生成されています。地理的に分散した環境では、サーバーへのラウンドトリップにはコストがかかるので、ラウンドトリップを可能な限り減らすことが目標になります。0 以外のキャッシュディレクティブを残りの各アイテムに追加すれば (ページは常にサーバーから返されるので除きます)、この目標を達成できます。BLOB キャッシュ機能は、このキャッシュディレクティブを追加する機能です。

BLOB キャッシュを構成するには、キャッシュを使用する Web アプリケーションの Web.config ファイルを使用します。メモ帳などのテキストエディタで Web.config ファイルを開き、BlobCache エントリを探します。既定では次のようになっています。

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js)$ " maxSize="10" enabled="false"/>

BlobCache 要素で使用されている属性には、次のような意味があります。

location ****: キャッシュされるアイテムが格納される Web サーバーのハードディスクドライブ上の場所を示します。
path : キャッシュする必要のあるファイルのタイプの regex 表現です。
maxSize : キャッシュが使用できるサイズ (GB 単位) です。
enabled **** : true に設定すると BLOB キャッシュが有効になります。

既定では含まれない次の追加属性は、個別のアイテムにキャッシュ有効期間を設定する場合に必要です。

max-age : クライアントコンピュータにアイテムをキャッシュしておく必要のある期間 (秒単位) です。

max-age 属性に 0 以外の値を設定すると、キャッシュ可能なアイテムにはキャッシュの有効期限の値が関連付けられ、ブラウザは、アイテムをダウンロードする必要や、さらには最新のバージョンかどうかを検証する必要さえなくなります。たとえば、キャッシュを有効にし、アイテムの格納用に Web サーバーに最大 100 MB を割り当てるものとします。1 日に 1 回有効期限が切れるようにし、キャッシュ対象として定義済みのタイプに加えて, .htc ファイルもキャッシュすることにします。これらの要件を実現するには、次のような BlobCache 属性を指定します。

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js|htc)$ " maxSize="100" max-age="86400" enabled="true"/>

Web.config ファイルに対するこの変更は、ファーム内のすべての Web サーバーで行う必要があることに注意してください。通常、BLOB キャッシュは直ちに機能し始めますが、変更を実装するときは、iisreset コマンドを使用するのが最も安全です。次のスクリーンショットは、前に示したものと同じページ要求について、説明したように BLOB キャッシュを有効にする点だけを変更したものの、Fiddler データを示しています。

Fiddler ツールの結果

/SiteCollectionImages ライブラリ内のすべてのアイテムの HTTP 状態コードが、200 になっていることに注意してください。これは、これらのアイテムが正常にダウンロードされたことを示しています。さらに、これらにはすべて、有効期限として 1 日 (8,400 秒) を指定したキャッシュディレクティブが関連付けられています。ページが再び要求された場合、Fiddler では再び要求された画像がないことが示されています。これにより、ページを提供するための要求の総数は 44 から 3 に減少し、そのうちの 2 つは、Web サーバーとクライアントアプリケーションの間で発生する NTLM 認証ネゴシエーションによるものです。次の図は、ページが再び要求されたときの Fiddler のデータを示しています。

Fiddler ツールの結果

さらに、BLOB キャッシュを使用するときは次のことを考慮します。

各 Web サーバーで Web.config ファイルを更新する必要があるので、構成作業が若干増えます。ただし、メリットはこの作業に十分見合うものです。
サイトのコンテンツを調査し、キャッシュから提供する必要のあるファイルタイプが他にもあるかどうかを判断する必要があります。代表的な例は .htc ファイルです。.htc ファイルはほとんどの発行サイトで使用されるので、キャッシュ対象のファイルタイプのリストにこのファイルタイプを追加する必要があります。
BLOB キャッシュは、SharePoint ライブラリに格納されているアイテムに対してのみ機能します。他のソースからのコンテンツのキャッシュには使用できません。
一部のリストは、匿名ユーザーに対しては既定では動作しません。匿名ユーザーがサイトにアクセスする場合は、次のリスト内のアイテムをキャッシュするには、次のリストに対してアクセス許可を手動で構成する必要があります。
- マスタページギャラリー
- スタイルライブラリ

BLOB キャッシュを使用するときには、他に 2 つの構成オプションがあることを知っておく必要があります。最初のオプションは、BLOB キャッシュのクリアと関係があります。特定のサイトについてキャッシュをクリアする必要がある場合は、そのサイトコレクションに移動し、[サイトの操作] メニューの [サイトの設定] をクリックし、[すべてのサイト設定の変更] をクリックします。[サイトコレクションの管理] のタスクの一覧で、[サイトコレクションのオプジェクトキャッシュ] リンクをクリックします。[ディスクベースのキャッシュのリセット] セクションで、[このサーバーでディスクベースのキャッシュのリセットを強制する] チェックボックスをオンにして、[OK] ボタンをクリックします。

SharePoint ファームで Web ガーデンを使用することを検討する場合は、Web ガーデンを使用すると、BLOB キャッシュが一貫性のない動作をするように見えることを理解しておく必要があります。複数の Web ガーデンをサーバーファームに構成すると、そのうちの 1 つしか BLOB キャッシュの管理に必要なロックを取得できないので、問題が発生します。その結果、BLOB キャッシュが断続的にしか動作していないように見える可能性があります。BLOB キャッシュが正常に使用されるかどうかは、どのスレッドが要求に対応するかによって決まります。

IIS 圧縮

以前のバージョンの SharePoint 製品とテクノロジとは異なり、SharePoint 製品とテクノロジをインストールすると IIS 圧縮が自動的に有効になります。何人かのユーザーがサイトにアクセスした後、Web サーバーの %WINDIR%\IIS Temporary Compressed Files ディレクトリを見ると、圧縮が動作していることを確認できます。このディレクトリには、通常、複数のファイルが含まれており、これは静的ファイルが要求され、IIS がそのコピーを圧縮してローカルドライブに格納したことを示しています。そのファイルが再び要求されると、同じユーザーかどうかにかかわらず、圧縮バージョンのファイルがこのフォルダから直接提供されます。動的なファイルも圧縮できますが、常にそのたびに圧縮が行われて、ローカル Web サーバーにコピーが保存されることはありません。

圧縮を行うと、帯域幅を大きく節約できます。たとえば、core.js ファイルはすべての SharePoint ページに含まれます。圧縮されていない状態では 257 KB ですが、IIS 圧縮でさらにチューニングしなくても、圧縮後にはわずか 54 KB になります。core.js はユーザーが初めてサイトにアクセスした後でキャッシュする必要がありますが、この例は、低帯域幅のシナリオにおいて圧縮がどれほど役に立つかを示しています。

SharePoint 製品とテクノロジをインストールすると、セットアップによって IIS は静的ファイルタイプ .htm, .html、および .txt を圧縮するように構成されます。IIS は、動的ファイルタイプの .asp と .exe も圧縮します。実装で広く使用されているファイルタイプを調査し、他のファイルタイプも圧縮されるように構成すると有効な場合があります。たとえば、多くの場合、静的ファイルタイプの .css と .js も圧縮することは意味があります。また、動的ファイルタイプ .axd および .aspx も圧縮すると有効です。

圧縮対象タイプのリストに静的または動的ファイルタイプを追加するには、各 Web サーバーの %SystemDrive%\Inetpub\AdminScripts フォルダに既定で存在する adsutil.vbs ファイルを使用します。次に示す例は Microsoft Windows Server 2003 のもので、圧縮される静的ファイルタイプのリストに css ファイルと js ファイルが含まれています。

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcFileExtensions "htm" "html" "txt" "css" "js"
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcFileExtensions "htm" "html" "txt" "css" "js"

次に示す例では、動的ファイルタイプのリストに .aspx ファイルと .axd ファイルが含まれています。

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "exe" "axd" "aspx"
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "exe" "axd" "aspx"

圧縮されるファイルタイプを変更するときは、圧縮に適したファイルのみを含めるようにしてください。たとえば, .jpg ファイルは、もともと既に圧縮されているファイルタイプなので、圧縮するのには適していません。また、2007 Microsoft Office system の docx、xlsx、pptx などのファイルタイプは、サーバーから直接提供されるものではないので、やはり圧縮には適していません。これらのファイルタイプは、Microsoft Office コンテンツ用のリッチな統合エンドユーザー環境の管理に使用される別の ISAPI フィルタを通してルーティングされます。さらに、2007 Microsoft Office system では、これらのファイルタイプはもともと圧縮されています。

圧縮するファイルのタイプを制御するだけでなく、動的ファイルタイプで使用される圧縮のレベルも制御できます。0 ～ 10 のスケールに基づいて、使用される圧縮量が決まります。圧縮レベルが高いほど、ファイルは小さくなります。ただし、圧縮レベルを高くするのと引き換えに CPU の使用量も増えるので、作成されるファイルを小さくするほど、圧縮での CPU の使用率は大きくなります。IIS 圧縮を有効にすると、使用する圧縮レベルは 0 に構成されます。経験上、SharePoint 製品とテクノロジでの最善の圧縮レベルは 9 です。圧縮レベルを変更するには、既に説明した adsutil.vbs スクリプトファイルを使用します。次に示すのは、圧縮レベルを 9 に変更する例です。

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel "9"
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel "9"

注意

この設定では、静的ファイルの圧縮は変更されません。

詳細については、「Using HTTP Compression (IIS 6.0) (英語)」(https://go.microsoft.com/fwlink/?linkid=108705&clcid=0x411) を参照してください。

BLOB キャッシュと IIS 圧縮を結合する

BLOB キャッシュを有効にすると、ユーザーが SharePoint サイトを参照するときにネットワーク経由で送信されるサーバーラウンドトリップとファイルの数が大幅に減少します。BLOB キャッシュと共に圧縮も使用すると、クライアントに送信されるこれらのファイルのトラフィック量も減少します。両者を組み合わせることで、ネットワークトラフィックの総量と、ネットワークおよびサーバーのリソースに対する競合を、大きく減らすことができます。

このブックをダウンロードする

このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なブックに収められています。

Office SharePoint Server 2007 の計画とアーキテクチャ、パート 2

入手できるすべてのブックの一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。

WAN 環境用に Office SharePoint Server を最適化する

WAN のトポロジを設計する

コンテンツのクロールのためにトポロジを最適化する

ローカル コンテンツ クロールの専用 Web サーバーを構成する

リモート ファームのクロール用に専用 Web サーバーを構成する

クエリのパフォーマンスのために最適化する

ファーム サーバーを地理的に分離する

コンテンツ クロール プロセスを最適化する

コンテンツ ソースのクロールを調整する

クロール頻度を構成し、フル クロールと増分クロールを調整する

クロール設定を構成する

検索のタイムアウト設定

タイムアウトの設定を指定する

クローラ影響ルール

クローラ影響ルールを追加する

WAN アクセラレータと他のサードパーティ ツール

WAN アクセラレータ

オフロードとキャッシュ デバイス

クライアント ソリューション

データ レプリケーション、マルチマスタ同期、および構成管理

マルチファーム管理性とレポート

バイト レベルまたはハードウェア ベースのレプリケーション

ダウンロードの時間が短くなるようにページを設計する

ページの要素

ページのダウンロードを最適化する

BLOB キャッシュ

IIS 圧縮

64 ビット ハードウェア

Web ガーデンの設定

ページ上のセキュリティ保護されたアイテムを最小限に抑える

画像の数とサイズを最小限に抑える

core.js のダウンロードを遅らせる

リスト ビュー ページを最適化する

WAN 環境でのキャッシュを最適化する

BLOB キャッシュ

IIS 圧縮

BLOB キャッシュと IIS 圧縮を結合する

このブックをダウンロードする

関連項目

概念

その他のリソース

ローカルコンテンツクロールの専用 Web サーバーを構成する

リモートファームのクロール用に専用 Web サーバーを構成する

ファームサーバーを地理的に分離する

コンテンツクロールプロセスを最適化する

コンテンツソースのクロールを調整する

クロール頻度を構成し、フルクロールと増分クロールを調整する

WAN アクセラレータと他のサードパーティツール

オフロードとキャッシュデバイス

クライアントソリューション

データレプリケーション、マルチマスタ同期、および構成管理

バイトレベルまたはハードウェアベースのレプリケーション

64 ビットハードウェア

リストビューページを最適化する