[方法] SharePoint Server 2007 Web コンテンツ管理サイトのパフォーマンスを最適化する

[アーティクル]
03/08/2010

概要 : 高いパフォーマンスと効果的なユーザーの操作性を実現するインターネット用 Web コンテンツ管理 (WCM) サイトの最適化方法について学習します。(9 印刷ページ)

Avneesh Kaushik、Microsoft Global Services India (MGSI)

2007 年 9 月

適用対象 : Microsoft Office SharePoint Server 2007

WCM サイトのパフォーマンス最適化の概要
ページペイロードを管理する (小さくする)
サーバー応答時間を最適化する
パフォーマンスを向上するサイトアーキテクチャを設計する
ネットワーク構成を最適化する
カスタムコード、コントロール、およびパフォーマンス
まとめ
追加情報
作成者について

WCM サイトのパフォーマンス最適化の概要

サイトの成功と失敗に影響する可能性があるため、パフォーマンスはインターネット用サイトで非常に重要な側面です。Microsoft Office SharePoint Server 2007 を使用すると、インターネット用 Web コンテンツ管理 (WCM) サイトを展開できます。Office SharePoint Server 2007 では多数のパフォーマンス最適化が行われているため、この機能を十分に理解し、最初からパフォーマンスという観点で、インターネット用 WCM サイトを設計する必要があります。現場では、ほとんどの Office SharePoint Server の展開はイントラネット指向ですが、サイトをインターネットで公開する場合は、ページペイロード (ページサイズ) などの独自の問題があります。イントラネットの展開では影響がなくても、インターネット用サイトでは大きな問題になる場合があります。ここでは、文書で十分に裏付けられている技術と、文書でまだ十分に裏付けられていない技術で、SharePoint WCM サイトのパフォーマンスを向上する技術のいくつかについて説明します。一般的な Web サイトのパフォーマンスに関するすべてのベストプラクティスは、SharePoint WCM に適用されます。

ページペイロードを管理する (小さくする)

Office SharePoint Server では、組み込まれた機能を使用して、最小限の労力で、非常に簡単に WCM サイトを展開できます。ただし、クライアントに送信される最終的な HTML については、ほとんど制御できません。ここでは、追加されるファイルと、そのファイルの処理に適した方法を詳しく説明します。

SharePoint コアファイル

WCM サイトで直面する大きな問題は、SharePoint のページ処理パイプラインによって、core.js、core.css、init.js、および ie55up.js など、特定の既定のファイルが追加され、元のページサイズに未圧縮で約 500 KB 追加され、ページペイロード、つまりページサイズにかなり余分な重みが追加されることです。この余分な KB によって、低速接続の場合は、ダウンロードの時間が、10 ～ 20 秒追加され、サイトのパフォーマンスが許容できないほどになります。Office SharePoint Server が正しく機能するにはこれらのファイルが必要なため、Office SharePoint Server は実行時にこれらのファイルをページに自動的に追加します。これらのファイルを Office SharePoint Server から簡単に削除したり、これらのファイルを変更することはできません。ただし、ほとんどの WCM サイトでは、さまざまなユーザーインターフェイス (UI) のカスタマイズが求められるため、これらのファイルは必要がない可能性があります。たとえば、さまざまな Office SharePoint Server 機能に必要とされる core.js ファイルは、インターネット用セクションで表示される SharePoint 機能がサイトになければ必要ない可能性がありますが、管理モードや作成モードには必要である可能性があります。この問題は、以下の方法で解決できます。

core .js ファイル (未圧縮で～ 250 KB) をバックグラウンドで (非同期に読み込んで) 読み込みを遅延させ、ページの読み込みを速くして、ユーザーがより迅速に利用できるようにする。.js ファイルが非同期に読み込まれるため、読み込みの遅延でユーザーの操作性が向上します。これは、最も安全なオプションでもあります。
core.js は必要な場合のみ読み込む。たとえば、高度にカスタマイズされたインターネット用 WCM サイトの場合、サイトの作成者、または管理者を除いて、ほとんどのユーザーには必要ない可能性があります。サイトにこのソリューションを適用すると、パフォーマンスに大きな違いが生じます。ただし、このオプションは正式にはサポートされていません。

匿名ユーザーに対してバックグラウンドで core.js ファイルを読み込むには

ユーザー設定のマスタページを作成します。
匿名ユーザーに対するマスタページの一部として core.js を必要とする Office SharePoint Server コントロールがないことを確認します (たとえば、[サイトの操作] メニューには必要です)。
サイトマスタページに core.js を登録する ScriptLink コントロールがないことを確認します。
以下の注釈をユーザー設定のマスタページに追加するか、新しいページレイアウトを作成して、レイアウトに注釈を追加します。Scriptlink コントロールをマスタページ、またはページレイアウトに追加する決定は、core.js ファイルの読み込み遅延動作をサイト全体に実装するか、新しいカスタムページレイアウトに基づいて特定のページのみに実装するかにより異なります。
```
<SharePointWebControls:ScriptLink runat="server"/>
```
新しい Microsoft Visual C# クラスプロジェクトを作成します。セクション A からコードをコピーします (以下の手順参照)。コードをコンパイルして、新しいバイナリファイル NoCoreLoad.dll を作成します。
NoCoreLoad.dll をグローバルアセンブリキャッシュ、または _app_bin に追加します (Web アプリケーション用)。
グローバルアセンブリキャッシュに追加した場合は、正しい公開キートークンと一緒に、Web アプリケーションの web.config ファイルに以下の行を追加します。

注意

このコード例には、オンライン表示を見やすくするために改行が含まれています。コードを実行する前に、改行を削除する必要があります。
```
<SafeControl Assembly="NoCoreLoad, Version=1.0.0.0, Culture=neutral, 
PublicKeyToken=XXXXXXXXXX" Namespace="Microsoft.IW" TypeName="*" 
Safe="True" />
```
タグを追加して、新しいバイナリを登録します。以下のような表示になります (ただし、PublicKeyToken は異なります)。

注意

このコード例には、オンライン表示を見やすくするために改行が含まれています。コードを実行する前に、改行を削除する必要があります。
```
<%@ Register TagPrefix="NoCoreLoad" Namespace="Microsoft.IW" 
Assembly="NoCoreLoad, Version=1.0.0.0, Culture=neutral, 
PublicKeyToken=XXXXXXXXXXXXXXXXX" %>
```
以下の注釈をヘッダー内のページの上部、他の .js ファイルの横に追加します。
```
<NoCoreLoad:RegisterCoreWhenAuthenticatedControl runat="server"/> 
```
CorePreLoad.aspx ファイルの内容をサーバーの _layouts ディレクトリにコピーします (次の手順のセクション B 参照)。(これにより、core.js ファイルが非同期で読み込まれます)。
ページレイアウトを使用している場合、サイトによって使用されているマスタページで、以下のように表示される注釈の </form> タグの後、</body> タグの前に新しいプレースホルダを追加します。
```
<asp:ContentPlaceHolder id="PlaceHolderBottomIFrame" runat="server" />
```
次に、ページレイアウトに以下の注釈を追加します。
```
<asp:Content ContentPlaceholderID="PlaceHolderBottomIFrame" runat="server">
<iframe src="https://blogs.msdn.com/_layouts/CorePreLoad.aspx" style="display:none"/>
</asp:Content>
```
あるいは、以下の変更を (サイト全体の) マスタページでのみ加えている場合は、上記の注釈をプレースホルダではなくマスタページに追加します。

マスタページだけでなく、新しいページレイアウトを使用して上記の手順を実行している場合は、ページレイアウトに基づいて新しいページを作成して機能をテストする必要があります。

認証されたユーザーの場合のみに読み込まれる core.js ファイルを条件付きで読み込むには

上記の手順 9. までを繰り返し、手順 9. 以降のステップを省略します。

このようにすると、core.js は認証されたユーザーに対してのみ読み込まれます。匿名ユーザーの場合、core.js は読み込まれません。必要に応じて、セクション A のコード例のロジックは、NTLM で認証されたユーザーの場合のみに core.js が読み込まれるようにさらに修正することができます。たとえば、コンテンツを作成するユーザーには、core.js が必要ですが、ほとんどの場合、これらのユーザーは、Windows で認証されたユーザーです。このような場合、認証された NTLM ユーザーに対してのみ、core.js を読み込むのが適切です。

注意

このコード例には、オンライン表示を見やすくするために改行が含まれています。コードを実行する前に、改行を削除する必要があります。

セクション A: NoCoreLoad.Dll
```
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Microsoft.SharePoint;
using System.Xml;
using System.Xml.Serialization;

namespace Microsoft.IW
{
    public class RegisterCoreWhenAuthenticatedControl : WebControl
    {
        protected override void OnInit(EventArgs e)
        {
            if (HttpContext.Current.Request.IsAuthenticated)
            {

                 Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);
            }
            base.OnInit(e);
        }
    }
}
```
セクション B: CorePreLoad.aspx
```
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" 
Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, 
PublicKeyToken=71e9bce111e9429c" %>
<html>
<head>
<title>Pre-Load Core.js</title>
</head>
<body>
<SharePoint:ScriptLink name="core.js" runat="server" />

<script language="javascript">
 DisableRefreshOnFocus();
</script>

</body>
</html>
```

ブラウザキャッシュ設定

資産 (例 : イメージ、または .js ファイル) を読み込む方法と頻度に影響する可能性のあるブラウザ、またはクライアントキャッシュ設定はいくつかあります。これらの設定が適切に構成されていれば、同じファイルの以降の読み込みに関して、パフォーマンスに影響を及ぼすことができます。これはほとんどのシナリオに該当します。適切な構成を行うと、サーバーとクライアントの両方で、帯域幅の使用も節約されます。これらの設定は、キャッシュプロファイルの設定、および Office SharePoint Server を実行するサーバーの BLOB またはディスクキャッシュの構成により影響を受けます。これについては、次のセクションで詳しく説明します。

MetaTagsGenerator を使用して、特定のページがクライアントでどうキャッシュされ、いつ有効期限が切れるかを制御することもできます。

<meta name="expires" content="Wed, 7 Mar 2006 15:52:37 GMT">
<meta http-equiv="cache-control" content="max-age 10">

これらのタグを微調整することにより、全体的なページの読み込みと表示で大きな違いが生じ、ユーザーの操作性が向上します。

IIS 圧縮

SharePoint サイトのパフォーマンスの向上 (特にサイズの大きいページの場合) に使用できる重要なオプションの 1 つは、インターネットインフォメーションサービス (IIS) 圧縮です。IIS 圧縮を変更するオプションは、IIS 6.0 で提供されています。SharePoint サイトで IIS 圧縮をオンにするのは簡単ではありません。ただし、先に進む前にいくつかのことを理解する必要があります。

IIS では、2 種類の圧縮機能が提供されています。

静的圧縮 .js ファイル, .html ファイルなどの静的資産の圧縮 (イメージは既に圧縮されているため、イメージは含まない)。静的圧縮は、サーバー負荷にほとんど影響を与えない、非常に簡単で単純なプロセスです。この方法では、ファイルは最初にアクセスされたときに圧縮され、一時フォルダに保存され、それ以降、一時ディレクトリからユーザーに提供されます。ほとんどの場合、50% を超える圧縮が簡単に可能で、ファイルサイズを大幅に削減できます。Office SharePoint Server の場合、_layout ディレクトリのすべてのファイル (例 : .js ファイルおよび .html ファイル) が圧縮されます。性質上静的なファイルを含めてその他すべてのファイルは、Office SharePoint Server 内に保存されている場合、静的として処理されません。主に、大きな core.js ファイルが圧縮され、サイズは約 250 KB から 57 KB に減少します。また、init.js や init55up.js などのような他のシステム .js ファイルも圧縮され、ページサイズに関する最大の問題を解決します。
動的圧縮 SharePoint サイトに対して動的圧縮をオンにするのは適切な選択肢とは言えず、避ける必要があります。圧縮オプションに関する詳細については、「SharePoint Deployment Capacity & Performance Planning 2003 & 2007: What you need to know...」を参照してください。

マスタページとページレイアウトの設計

サイト開発開始時に、パフォーマンスを念頭に置いてマスタページとページレイアウトを設計することも非常に重要です。HTML 開発に関する昔からのベストプラクティスも考慮する必要があります。

HTML のベストプラクティス

ドキュメントの場合 :

ドキュメントは、HTML または XHTML として検証する必要があります (「W3C Markup Validation Service」)。

注意

Office SharePoint Server は、既定では XHTML 準拠ではありません。
ドキュメントには、DTD が必要です。
ドキュメントには、HTTP ヘッダー、またはメタタグを使用した文字エンコード (「W3C Recommendation: 5.2.1 Choosing an encoding」) が必要です。

ドキュメントには、以下のように定義された言語が必要です。

<html lang="en"> 
<html xml:lang="en"> 
<meta name="content-language" content="en">

属性および要素の場合 :

属性の値は、引用符で区切る必要があります (「W3C Recommendation: 3.2.2 Attributes」)。XHTML では、引用符が必須です (「W3C Recommendation: 4.4. Attribute values must always be quoted」)。
要素名と属性名では、読みやすさのため、大文字と小文字の使い方を統一してください。XHTML 互換性のため、小文字が優先されます。

イメージの場合 :

イメージ、イメージマップ、およびスクリプト化されたコンテンツには、適切な値の alt 属性が必要です (「W3C Recommendation: 13.8 How to specify alternate text」)。
イメージデータを待っている間も、ブラウザが表示を継続できるように、イメージでは、常に幅と高さが指定されている必要があります (「W3C Recommendation: 13.7.1 Width and height」)。

特殊文字の場合 :

" (")、< (<)、> (>)、および & (&) などの一部の特殊文字は、特に href または src などの属性内では、常に文字エンティティ、または番号文字参照 (NCR) で置き換える必要があります (「W3C Recommendation: B.2 Special characters in URI attribute values」)。
ISO 8859-1 の € など、文字セットに含まれていない文字は置き換える必要があります。W3C I18N 活動グループは、"–" (半角ダッシュ) など、その他の特殊文字も置き換えることを勧めていますが、ドイツ語の "ü" やフランス語の "é" などの一般的な文字については、コードの読みやすさを維持するため置き換えを勧めていません (「W3C Architecture Domain Internationalization: FAQ: Using character entities and NCRs」)。

スクリプトや style タグの場合 :

スクリプトおよび style タグには type 属性が必要です (「W3C Recommendation: 18.2.1 The SCRIPT element」)。
キャッシュとメンテナンスのため、外部ファイルを使用して、ECMAScript (JScript、JavaScript) コードを含める必要があります。

言うまでもなく、ブラウザキャッシュ (「Performance Research, Part 2: Browser Cache Usage—Exposed!」) および HTTP 要求 (「Performance Research, Part 1: What the 80/20 Rule Tells Us About Reducing HTTP Requests」) については、スクリプト src="sample.js" による複数のサーバー要求で、または 1 つの要求と内部 HTML コードを使用して外部ファイルをより迅速に読み込めるかという論点もあります。ただし、いずれの場合でも一元化された、非冗長ファイルを使用する必要があります。

CSS のベストプラクティス

CSS は、検証が必要です (「CSS Validation Service)。
要素は、テーブルではなく、CSS 2 と一緒に配置する必要があります。
すべての装飾線、境界、背景色およびイメージ、下線、およびその他の装飾的要素は、CSS 2 で表示する必要があります。
テキストは、font タグではなく、CSS 1 で書式設定する必要があります。
すべてのスタイルシートは、HTML ファイル内の冗長コードとしてではなく、再利用可能、一元的にメンテナンス可能、キャッシュ可能な外部 CSS ファイルに含まれる必要があります。
外部 CSS ファイルは、正しい MIME の種類 (text/css) で送信する必要があります。
たとえば、CSS クラスと ID は、数字やアンダースコアではなく文字で開始し、有効である必要があります。ID は一意である必要があります。クラス名は一般的なもので、外観ではなく機能を記述する必要があります。

サーバー応答時間を最適化する

Office SharePoint Server 2007 では、WCM ページに対するサーバー側の応答を最適化し、Microsoft SQL Server を実行する Office SharePoint Server サーバーおよびバックエンドサーバーの負荷を削減する多数のオプションが提供されています。

Office SharePoint Server で、サーバー側のパフォーマンスを向上できるキャッシュオプションもいくつかあります。以降のセクションでは、これらのオプションをオンにする方法と、これらのオプションの構成で注意するべきことについて説明します。

インターネット用サイトのほとんどでは、ユーザーの大多数が匿名です。これらのシナリオで出力キャッシュを使用すると、サイトの全体的なパフォーマンスが大きく変わります。

出力キャッシュ

Office SharePoint Server 2007 では、以降のページ要求を処理するためのページのパーツのキャッシュに、ASP.NET によって提供される同じ技術が使用されています。キャッシュで HTML マークアップを節約すると、ページが要求されるたびに、同じ HTML マークアップを生成するコードを実行する必要がないため、ASP.NET は、少ない CPU 使用率とデータベースのラウンドトリップで、Web ページをはるかに迅速に提供できます。

出力キャッシュを有効にする前に、まだ有効にしていない場合は、サイトコレクションの MOSS 発行インフラストラクチャ機能を有効にする必要があります。既定で有効にされるかどうかは、サイトコレクションを作成するときに選択したサイトテンプレートにより異なります。

出力キャッシュの構成では、以下に注意してください。

出力キャッシュは、コンテンツを頻繁に更新する必要のない Web サイトに適しています。
出力キャッシュは、アクセスが匿名の場合により効果的です。
出力キャッシュは、各キャッシュページの HTML マークアップをキャッシュするために、余分なメモリを消費します。
2 台以上のフロントエンド Web サーバーと共に使用した場合、出力キャッシュは一貫性に影響を与えることがあります。
コンテンツを作成できる認証されたユーザーに対してキャッシュを有効にすると、最新のコンテンツを使用していない可能性があるため、問題が生じる場合があります。
パフォーマンスをさらに最適化する必要がある場合は、出力キャッシュの動作をサイトコレクション、サイト、およびページレイアウトの 3 レベルで指定することができます。
ユーザー認証を採用している環境では、検索結果をキャッシュしないようにします。
出力キャッシュを有効にした場合、プライベートバイトに対する既定の ASP.NET 2.0 制限を拡張する必要があることがあります。
認証されたユーザーをグループ化し、ユーザーのサイトに対するアクセス権に基づいてキャッシュ動作を有効にすると、認証されたユーザーに対するキャッシュパフォーマンスを向上できます。

キャッシュプロファイルを作成する必要のあるシナリオは、主に 2 つあります。ほとんどの場合、ユーザーには匿名ユーザーと認証されたユーザーの 2 種類があります。すべての匿名ユーザーは、同じキャッシュされたコンテンツを共有していますが、これは認証されたユーザーには適切ではありません。認証されたユーザーは、そのユーザーのためにキャッシュされたコンテンツのみを共有します。このため、キャッシュヒット率が大幅に低くなる場合があります。この動作を解決するソリューションは、ユーザーをグループまたは役割に分けて、同じキャッシュされたコンテンツを共有できるようにすることで、リソースをより適切に利用できます。

キャッシュプロファイルを作成、または編集するには

図 1 に示すとおり、出力キャッシュの動作を指定するキャッシュプロファイルを作成、または編集します。

図 1. キャッシュプロファイル
以下のプロパティと使用法を理解していることを確認してください。
- 有効 (キャッシュをオンにする)
- 時間 (キャッシュコンテンツを保持する時間)
- HTTP ヘッダーごとにキャッシュ
- キャッシュ可能 (キャッシュの動作)

出力キャッシュを有効にするには

匿名ユーザーと認証されたユーザーに対してキャッシュプロファイルを設定します。ユーザーの各種類に対して別々のプロファイルを設定できます。

図 2. 出力キャッシュ設定
[ページにキャッシュのデバッグ情報を表示する] チェックボックスを選択して、キャッシュの動作をテストします。このオプションを有効にすると、Office SharePoint Server によって提供される各ページの下部に "" と追加されます。

ディスクベースのキャッシュ

インターネット用の Web サイトでは、さまざまな UI のカスタマイズが可能です。これは、Office SharePoint Server を実行しているサーバー上に多数の大きなイメージ, .css ファイル、および .js ファイルが保存されることを意味します。これらのファイルは、SQL Server データベース内の BLOB として保存され (スタイルライブラリ、サイトコレクションイメージなどのように、SharePoint ライブラリに保存された場合)、サーバーのパフォーマンスに悪影響を及ぼす可能性があります。これらのファイルは、バックエンド SQL サーバーにも負荷を加えます。Office SharePoint Server では、BLOB キャッシュとも呼ばれるディスクベースのキャッシュが提供され、この問題を解決します。ディスクベースのキャッシュは非常に速く、これらのオブジェクトは、データベースから取得されてから、フロントエンド Web サーバーのファイルシステムに保存されるため、データベースのラウンドトリップのニーズをなくします。追加の要求は、キャッシュから提供され、セキュリティに基づいて切り捨てられます。このオプションは既定では無効にされており、サーバーファームで各フロントエンド Web サーバーの Web アプリケーションの web.config ファイルで、以下の行を修正する必要があります。

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

上記の XML では、以下に注意してください。

location は、キャッシュファイルが保存されるディレクトリです。
path は、正規表現の形式で、キャッシュされるファイルをファイル名の拡張子に基づいて指定します。
maxSize は、ギガバイト (GB) 単位でのディスクベースのキャッシュの最大許容サイズです。
max-age は、クライアントブラウザがクライアントコンピュータにダウンロードされた BLOB をキャッシュする最大時間を秒単位で指定します。これは、ブラウザのページヘッダーの一部として送信されたキャッシュのメタタグに影響します。これは、特に低速で接続している場合、クライアント側のパフォーマンスに大きく影響する可能性があります。ほとんどの .js ファイルとイメージファイルはダウンロードされ、クライアントキャッシュに保存され、このプロパティで指定された時間は再読み込みされません。
enabled は、キャッシュを無効、または有効にするブール値を指定します。

ディスクベースのキャッシュは、要求ごとのイメージ、js ファイル、およびその他の資産のダウンロード時間を低減します。max–age セグメントで指定された秒数は、ファイルが変更されていてもサーバーを確認せず、ローカルキャッシュから資産を読み込むようにブラウザに伝えます。ブラウザは、指定された秒数が過ぎてからファイル状況を確認し、変更が発見されるとイメージを再読み込みします。

また、マスタページギャラリーとスタイルライブラリは、既定では匿名ユーザーには機能しません。BLOB キャッシュをこれらのリストに対しても機能させるには、これらのリストに移動して、BLOB キャッシュへの匿名アクセスを明示的にオンにする必要があります。

オブジェクトキャッシュ

Office SharePoint Server 2007 は、Web パーツ、ナビゲーションデータ、およびクロスリストクエリによってアクセスされたデータなどのすべてのコンテンツとオブジェクトを SQL Server データベースに保存します。これらの項目は、ディスクベースのキャッシュ、または出力キャッシュではキャッシュされません。この場合、既定でオンにされるオブジェクトキャッシュが役立ちます。キャッシュにより、クロスリストクエリのパフォーマンスが向上します。オブジェクトキャッシュもページフィールドデータをキャッシュして、ページレンダリングを向上させます。ただし、Web パーツと関連データはキャッシュされません。

オブジェクトキャッシュのデフォルトサイズは、100 MB ですが、このキャッシュを最大限に活用するには、この数字の微調整が非常に重要です。キャッシュヒット率を確認せずにこのサイズを大きくしすぎると、他のキャッシュで使用できる貴重なメモリを無駄にする可能性があります。オブジェクトキャッシュが大きいと、32 ビットコンピュータで出力キャッシュに悪影響を与え、パフォーマンスにも悪影響が及ぶ場合があります。

SharePoint Publishing Cache Object パフォーマンスカウンタオブジェクトを使用して、オブジェクトキャッシュをプロファイリングすることをお勧めします。キャッシュヒット率と、Object Discard カウンタの変更に基づいて、オブジェクトキャッシュのサイズを増加できます。

パフォーマンスを向上するサイトアーキテクチャを設計する

SharePoint ベースのサイト (物理的な設定、トポロジなどを含む) のアーキテクチャと設計は、パフォーマンスに大きな影響を与える可能性があります。

ハードウェアと Office SharePoint Server ファームのトポロジに多くを依存するため、以下が必要になります。

SQL Server のハードウェア要件とフロントエンド Web サーバーへの接続性については、「SQL Server 2005 システム要件」の一般的なガイドラインに準拠する。
アプリケーションサーバー、インデックスサーバー、フロントエンド Web サーバーを別々の物理サーバーに分離する。
サーバー間で適切な接続性を確保する。
負荷と需要に基づいて、SQL Server を実行するサーバーをスケールアップし、フロントエンド Web サーバーをスケールアウトする。

SharePoint サイトを計画する場合の詳細については、以下のリソースを参照してください。

ハードウェア要件およびソフトウェア要件

ハードウェアおよびソフトウェアの要件を決定する (Office SharePoint Server)

Office SharePoint Server に関する計画とその他の背景情報

Office SharePoint Server 2007 の計画とアーキテクチャ

WCM に対して推奨される展開トポロジ

Solutions Using the Microsoft Office system

サイトコレクション、および関連ライブラリの設計に関するベストプラクティスに従うことも非常に重要です。慎重な検討が必要ないくつかの要素を以下に示します。

サイトあたりの最大ページ数 (2,000 とする)。リストにこの数字を超える項目があると、パフォーマンスに悪影響を与える可能性があります。
サイトあたり 1 つのページライブラリを使用
データベースあたりのサイトコレクションの数
各データベースのサイズ
SQL Server インスタンスあたりのデータベースの数
指定の SQL Server インスタンスの合計データベースサイズ
ファームあたりのポータルサイト、拡張された IIS 仮想サーバー、および Web アプリケーション
サーバーあたりのアプリケーションプール
サーバーあたりのワーカープロセスとアプリケーションプール
サイトコレクションの最大クォータ

詳細については、「SharePoint Deployment Capacity & Performance Planning 2003 & 2007 What You Need to Know...」を参照してください。

地理的に分散した Web サーバーファーム

非常にパフォーマンスの高い Web サイトを設計するために、地理的に分散、またはミラー化するという極端な方法もあります。クライアントと Web サイトサーバーとの間のホップ数も、パフォーマンスと全般的なユーザーの操作性に影響を及ぼす可能性があります。たとえば、ヨーロッパにいるユーザーが米国にある Web サーバーにアクセスすると、米国にいるユーザーが同じサイトにアクセスする場合に比べて、若干、ネットワーク遅延が大きくなります。Office SharePoint Server 2007 では、異なった配信先サーバーでコンテンツを公開する機能が提供されており、地理的に分散したさまざまなサーバー間でコンテンツの自動同期を容易にします。このメカニズムは、パブリッシングジョブと API を使用したコンテンツ展開に基づいています。Office SharePoint Server は、種類を問わずレプリケーションをサポートしていません。

ネットワーク構成を最適化する

ネットワーク構成は、Office SharePoint Server または Windows SharePoint Services のパフォーマンスにとってきわめて重要です。表 2 では、インストールのパフォーマンスに影響を与える可能性のある一般的なネットワークコンポーネントについて説明します。

表 2. インストールのパフォーマンスに影響を与える可能性のあるネットワークコンポーネント

項目	説明
ネットワークインターフェイスカード (NIC)	NIC 設定 : 可能な限り、ギガバイトネットワークカードを使用します。自動切り替えカード (100 MB/1 GB) を使用している場合は、常に 1 GB を使用するようにオーバーライドを設定します。受信/発信 : 大量のトラフィックが予想されるシナリオでは、受信トラフィックと発信トラフィックを処理する NIC を分けることをお勧めします。
スイッチ	スイッチを介してネットワークを実行している場合は、GB スイッチを使用し、受信チャネルと発信チャネルが同じ数であることを確認します。
ルーター	ルーターが GB インフラストラクチャで構成されていることを確認します。
ドメインコントローラ	ドメインコントローラ (DC) が、応答可能な速度を超えて要求を受信する場合、認証が SharePoint 環境におけるパフォーマンスのボトルネックになる可能性があります。NTLM などのユーザー認証を使用する環境では、DC ごとに 3 フロントエンド Web サーバーという比率を推奨します。テストによって DC ごとに 3 フロントエンド Web サーバーの認証負荷が許容可能であることがわかった場合は、DC ごとに 4 フロントエンド Web サーバーというサポート制限に合わせて、DC ごとにフロントエンド Web サーバーをもう 1 つ追加することができます。

ネットワーク構成は、システムを実稼働環境に移行する前に、完全に計画およびテストする必要があるということに注意してください。

詳細については、「パフォーマンスと容量の計画に影響を与えるその他の要因 (Office SharePoint Server)」の「環境要因」を参照してください。

カスタムコード、コントロール、およびパフォーマンス

SharePoint サイトで最も考慮されていない分野の 1 つとして、カスタムコード、またはカスタムコントロールが挙げられます。これらのコントロールは、Office SharePoint Server のパフォーマンスに通常悪影響を及ぼす可能性があります。

カスタムコントロールを作成する場合は、以下の側面を考慮してください。

SQL Server のラウンドトリップ
CPU 利用率
ページのダウンロードサイズ
クライアント側コードの効率
AJAX コールバック

これは、キャッシュ対応のカスタムコントロールの作成にも重要です。マスタページとページレイアウトのカスタムコントロールでは、サーバーのラウンドトリップを最小限に抑え、常にオブジェクトキャッシュを使用するナビゲーションプロバイダの構築やコンテンツクエリキャッシュを使用したコンテンツクエリの作成など、組み込みの Office SharePoint Server キャッシュ機能を使用します。常に、ASP.NET に組み込まれたキャッシュ機能を使用できるようにコントロールをコード化することをお勧めします。また、使用されなくなった SharePoint オブジェクトを直ちに破棄し、ビュー状態を最低限に維持するなど、一般的に適切なコード化のガイドラインに注意してください。可能な限り、Office SharePoint Server で利用可能なデータを使用すると、パフォーマンスの大幅な向上に役立ちます。

Office SharePoint Server では、CrossListQueryCache クラスなど、カスタムコントロールのパフォーマンスを最適化する多数の基本コントロールクラスが提供されています。

まとめ

インターネット用 WCM サイトでは、イントラネットのインストールに比べて、パフォーマンスが非常に重要な要素になります。パフォーマンスは、環境、コントロール、UI、および設計など、多数の要素による影響を受けます。WCM サイトを適切に設計するには、簡単な Web サイトより多くの労力が必要です。Office SharePoint Server 2007 では、使用しているハードウェアから、最適なパフォーマンスが得られるように、構成を微調整するさまざまな方法が提供されています。Office SharePoint Server により提供されているすべての利用可能なオプションについて学習し、利用してください。ここで説明したガイドラインに準拠して、適切な構成で Office SharePoint Server を展開すれば、非常に良い結果が得られます。

追加情報

高いパフォーマンスと効果的なユーザーの操作性を実現するインターネット用 WCM サイトの最適化の詳細については、以下のリソースを参照してください。

作成者について

Avneesh Kaushik は、Microsoft Global Services India (MGSI) の IW/Collaboration サービスラインに勤務するシニアコンサルタントです。Hawaiian Airlines WCM サイトの設計と展開に参加しています。

[方法] SharePoint Server 2007 Web コンテンツ管理サイトのパフォーマンスを最適化する

WCM サイトのパフォーマンス最適化の概要

ページ ペイロードを管理する (小さくする)

SharePoint コア ファイル

匿名ユーザーに対してバックグラウンドで core.js ファイルを読み込むには

認証されたユーザーの場合のみに読み込まれる core.js ファイルを条件付きで読み込むには

ブラウザ キャッシュ設定

IIS 圧縮

マスタ ページとページ レイアウトの設計

サーバー応答時間を最適化する

出力キャッシュ

キャッシュ プロファイルを作成、または編集するには

出力キャッシュを有効にするには

ディスク ベースのキャッシュ

オブジェクト キャッシュ

パフォーマンスを向上するサイト アーキテクチャを設計する

地理的に分散した Web サーバー ファーム