[方法] SharePoint Server 2007 Web コンテンツ管理サイトのパフォーマンスを最適化する
概要 : 高いパフォーマンスと効果的なユーザーの操作性を実現するインターネット用 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. キャッシュ プロファイル
.gif "キャッシュ プロファイル")
以下のプロパティと使用法を理解していることを確認してください。
有効 (キャッシュをオンにする)
時間 (キャッシュ コンテンツを保持する時間)
HTTP ヘッダーごとにキャッシュ
キャッシュ可能 (キャッシュの動作)
出力キャッシュを有効にするには
匿名ユーザーと認証されたユーザーに対してキャッシュ プロファイルを設定します。ユーザーの各種類に対して別々のプロファイルを設定できます。
図 2. 出力キャッシュ設定
.gif "出力キャッシュの設定")
[ページにキャッシュのデバッグ情報を表示する] チェック ボックスを選択して、キャッシュの動作をテストします。このオプションを有効にすると、Office SharePoint Server によって提供される各ページの下部に "<!--2006-11-03T14:38:59 にキャッシュ プロファイル Public Internet を使用して表示されました -->" と追加されます。
ディスク ベースのキャッシュ
インターネット用の 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 に関する計画とその他の背景情報
WCM に対して推奨される展開トポロジ
サイト コレクション、および関連ライブラリの設計に関するベスト プラクティスに従うことも非常に重要です。慎重な検討が必要ないくつかの要素を以下に示します。
サイトあたりの最大ページ数 (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) |
|
スイッチ |
スイッチを介してネットワークを実行している場合は、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 サイトの設計と展開に参加しています。