BLOB キャッシュを WAN 環境用に最適化する (SharePoint Server 2010)

 

適用先: SharePoint Server 2010

トピックの最終更新日: 2016-11-30

この記事では、Microsoft SharePoint 2010 製品の BLOB キャッシュを WAN 環境で使用する方法について説明します。

一般に、キャッシュは、要求をサーバーで受信してからクライアント コンピューターへの応答のストリームを開始するまでの、レンダリング パイプラインのスループットを高める方法と認識されています。これは、サイトのパフォーマンス全体にとっての重要な側面ですが、このセクションでは、キャッシュに関する次の内容について説明します。

• クライアント キャッシュに関するサーバー構成の役割。

• ネットワーク経由でサーバーからクライアントに伝送されるアイテムのサイズの制御。

BLOB キャッシュについて

BLOB キャッシュは、SharePoint Server 2010 発行機能でのみ使用できるメカニズムです。これは、グループ作業ポータル サイト テンプレートに基づく企業ポータル サイトと、発行ポータル サイト テンプレートに基づくインターネット用サイトには特に推奨されます。BLOB キャッシュを使用すると、ページ ライブラリやサイト コレクションのイメージなど、発行サイト リストから提供されるキャッシュ ディレクティブを構成できます。クライアント コンピューターのブラウザーはキャッシュ ディレクティブを検出すると、取得するアイテムをローカルに保存できることを検知するため、キャッシュ ディレクティブの有効期間が終了するまでアイテムを再度要求する必要はありません。地理的に分散している環境ではこれが特に重要で、ネットワーク経由で要求および送信されるアイテムの数が減少します。

SharePoint Server 2010 の BLOB キャッシュを有効にすると、2 つの異なる処理が発生します。まず、キャッシュ可能なアイテムの要求があるたびに、SharePoint Server 2010 は、要求を受信した Web サーバーのハード ディスク ドライブを検索して、アイテムのローカル コピーが存在するかどうかを確認します。アイテムのローカル コピーが存在する場合は、ファイルは、ローカル ディスクからユーザーに直接ストリームされます。ローカル ディスクにアイテムのコピーが存在しない場合は、アイテムの保存元の SQL データベースからアイテムのコピーが作成されて要求元のユーザーに返されます。その後、そのアイテムに対する要求はすべて、アイテムのキャッシュ可能値が示す有効期間が終了するまで、Web サーバーから直接取得されます。その結果、データベース サーバーで競合することが少なくなるため、サーバー ファームのパフォーマンスが向上します。

また、BLOB キャッシュを有効にしていると、アイテムがクライアントに送信されるときに、キャッシュ可能ヘッダーがアイテムに追加されます。このヘッダーは、アイテムをキャッシュする必要がある期間をブラウザーに指示します。たとえば、画像のキャッシュ可能値が 3 日間に設定されている場合、ブラウザーは、次の 3 日間のうちにその画像が再度要求されると、ローカル キャッシュ内にある画像のコピーを使用して、その画像をサーバーに再度要求しません。

Fiddler を使用して BLOB キャッシュに関するデータを収集する

キャッシュするアイテムおよびアイテムのキャッシュ方法を確認するテストを実施するときは、無償で提供されている Fiddler (英語) (http://www.fiddlertool.com) というデバッグ アプリケーションを使用できます。次のスクリーンショットは、発行用の簡易的な SharePoint サイトを 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 ディレクトリにあります。アイテムがこのようなキャッシュ設定を持つ理由は、_layouts/images 仮想ディレクトリの IIS での構成方法にあります。新しい Web アプリケーションを作成すると、SharePoint Server 2010 は、Web サーバーの物理ディスク上のフォルダーにマップするいくつかの仮想ディレクトリを自動的に作成します。_layouts/images 仮想ディレクトリを作成するときに、ディレクトリ全体に適用されるキャッシュ ディレクティブが追加されます。次のスクリーンショットは、IIS マネージャー スナップインでのディレクトリの構成を示しています。

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

Fiddler のデータが示すとおり、アイテムの要求数は 44 から 11 に大幅に減少しています。ここで重要な点があります。それは、要求数はページの要求方法によって異なる可能性があるということです。ブラウザーの更新ボタンを使用すると、アイテムのローカル キャッシュが存在するかどうかにかかわらず、通常はすべてのアイテムが再度要求されます。一方、ページに移動するか、リンクまたはショートカットを使用してページを要求する場合は、キャッシュされていないアイテムのみが要求されます。

また、Fiddler のデータから次のこともわかります。ブラウザーがサーバーに要求しているマスター ページの他の画像は、既にローカル キャッシュに含まれています。304 応答コードがそれを示しています。つまり、ブラウザーは、アイテムを条件付きで要求しています。304 応答の意味は、サーバー側とクライアント側でバージョンは同じなので、再度ダウンロードする必要はないということです。ファイルがネットワーク経由でダウンロードされなくても、ローカル コピーが最新であるかどうかを調べるためにサーバーへのラウンドトリップが生成されます。地理的に分散している環境では、サーバーのラウンドトリップのコストが高くなります。したがって、このようなラウンドトリップをできるだけ低減する必要があります。それは、ページ以外の残りの各アイテム (ページは常にサーバーから返されます) にゼロ以外のキャッシュ ディレクティブを追加することで達成できます。そのキャッシュ ディレクティブを追加するのが BLOB キャッシュ機能です。

Web.config を使用して BLOB キャッシュを構成する

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

<BlobCache location="" path="\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$" maxSize="10" enabled="false" />

BlobCache 要素で使用される属性の意味は次のとおりです。

• location    キャッシュするアイテムの格納先となる Web サーバーのハード ディスク ドライブの場所を参照します。

• path   キャッシュする必要があるファイルの種類の RegEx 表現。

• maxSize **   **キャッシュで使用できるサイズ (GB)。

• enabled    BLOB キャッシュを有効にするには true に設定します。

個々のアイテムにキャッシュの有効期間値を設定するには、次の追加属性が必要です (既定では含まれません)。

• max-age   アイテムをクライアント コンピューターにキャッシュする期間 (秒単位)。

max-age 属性にゼロ以外の値を設定することで、キャッシュ可能なアイテムにキャッシュの有効期間値を関連付けます。これにより、ブラウザーは、アイテムをダウンロードする必要がなくなり、最新のアイテムであるかどうかを確認する必要もありません。たとえば、キャッシュを有効にし、アイテムを格納する領域として 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 コマンドを使用するのが最も安全です。次のスクリーンショットは、上記と同じページを要求した場合の Fiddler のデータを示しています。ここでは、BLOB キャッシュが有効になっています。

ここでは、/SiteCollectionImages ライブラリ内のすべてのアイテムに HTTP 状態コードの 200 が設定されています。これはアイテムが正常にダウンロードされたことを示すものです。また、どのアイテムにもキャッシュ ディレクティブが割り当てられ、有効期間が 1 日で終了するように設定されています (86,400 秒)。ページが再度要求されると、Fiddler は、再度要求する画像はないことを示します。その結果、このページを取得するために必要となる要求の合計数は 44 回から 3 回に減少します。また、その 3 回の要求のうち 2 回は単なる NTLM 認証で、Web サーバーとクライアント アプリケーションの間で発生します。次の図は、ページを再度要求したときの Fiddler のデータを示しています。

BLOB キャッシュを使用する場合の追加の検討事項

BLOB キャッシュを使用する場合は、次の点を考慮します。

• 各 Web サーバーの Web.config ファイルをアップグレードする必要があるため、作業上の負担が増します。ただし、その負担に見合うだけの利点があります。

• サイトのコンテンツを調べて、他のファイルの種類でキャッシュを使った方がよいものがないかを確認します。たとえば, .htc ファイルがあります。.htc ファイルは、ほとんどの発行サイトで使用されるため、このファイルの種類は、キャッシュするファイルの種類のリストに追加する必要があります。

• BLOB キャッシュは、SharePoint ライブラリに格納されるアイテムに対してのみ機能します。それ以外のソースからのコンテンツをキャッシュすることはできません。

• リストによっては既定で匿名ユーザーに対しては機能しない場合があります。匿名ユーザーがサイトにアクセスする場合は、次のリスト内のアイテムがキャッシュされるように、これらのリストに対してアクセス許可を手動で構成する必要があります。

  • マスター ページ ギャラリー

  • スタイル ライブラリ

BLOB キャッシュを操作するタイミングを認識するための構成オプションが他にも 2 つあります。1 つは、BLOB キャッシュの消去に関連するオプションです。特定のサイトについてキャッシュを消去する必要がある場合は、そのサイト コレクションを参照して、[サイトの操作]、[サイトの設定]、[すべてのサイト設定の変更] メニューを順にクリックします。サイト コレクションの管理タスクのリストで、[サイト コレクションのオブジェクト キャッシュ] リンクをクリックします。[ディスクベースのキャッシュのリセット] セクションで、[このサーバーでディスク ベースのキャッシュのリセットを強制する] チェック ボックスをオンにして [OK] をクリックします。