SharePointサイトテンプレートは、実際にはサイト定義よりも効率が悪いのですか？

StackOverflow https://stackoverflow.com/questions/612574

質問

だから、SharePointのブロゴスフィアでは、誰もが他のブログから同じ箇条書きをコピーして貼り付けるだけのようです。私が見た箇条書きの1つは、サイト定義がファイルシステムに保存されているため、SharePointサイトテンプレートはサイト定義よりも効率が低いことです。本当ですか？

サイトテンプレートの効率が低下するのは奇妙に思えます。サイトテンプレートを使用する場合でもサイト定義を使用する場合でも、すべてのサイトコンテンツはデータベース内に存在することを理解しています。サイトテンプレートはデータベースに1回適用され、それ以降、サイトテンプレートを使用してコンテンツが作成されたかどうかはサイトで気にする必要はありません。

では、サイトテンプレートがサイト定義よりも効率が悪いアーキテクチャ上の理由は何ですか？

編集：パフォーマンスに違いがあると言っているブログへのリンク：

  • MSDN から：テンプレートの保存が遅いためデータベースから取得すると、サイトテンプレートによりパフォーマンスが低下する可能性があります。
  • DevX より：ただし、SharePointのユーザーテンプレートはパフォーマンスにつながる可能性があります組織全体で再利用可能なテンプレートのセットを作成しようとしている場合、最適なアプローチではない可能性があります。
  • ITフットプリント：テンプレートの保存とデータベースからの取得が遅いため、サイトテンプレートはパフォーマンスが低下する可能性があります。データベース内のテンプレートは、ページがレンダリングされるたびにコンパイルおよび実行されます。
  • SharePointのブランディング：カスタムサイト定義には、カスタムテンプレートよりも次の利点があります。
    • データはWebサーバーに直接保存されるため、通常はパフォーマンスが向上します。

少なくとも、上記の記事は不完全だと思うし、SharePointのアーキテクチャについて知っていることに基づいて、いくつかの記事は誤解を招くと思う。

パフォーマンスの違いについて議論した別のブログ記事を読みましたが、リンクが見つかりません。

役に立ちましたか？

解決

サイトテンプレートを使用した場合とサイト定義を使用した場合のパフォーマンスへの影響は、一般的に誇張されています。

なぜ？

さて、この例を見てみましょう：

  1. チームサイトのサイト定義を取得します。
  2. 新しいサイトテンプレートとして保存します
  3. 次に、この新しいサイトテンプレートに基づいて新しいサブWebを作成します。

何を持っていますか？覚えておくべき重要なことは、「ゴースト」ということです。サイトレベルではなく、ページレベルで発生します。どのページもカスタマイズしていないため、アクセスするページはすべて、サイト定義から直接、ファイルシステムから直接来ています。

それを証明したい、2つのテストがあります：

最初のテスト

  1. 元のサイト定義のdefault.aspxページを変更してみてください。
  2. サイトテンプレートを確認し、変更が表示されることを確認します。
  3. まだ＆quot; Ghosted＆quot ;;ファイルシステムへ

2番目のテスト

  1. 新しいサイト定義を作成します。
  2. この新しいサイト定義に基づいて新しいサイトを作成します。
  3. 新しいサイトテンプレートの作成
  4. サイトテンプレートをSharePointのメンバーに送信し、それに基づいて新しいサブWebを作成するよう依頼します。

失敗します。どうして？サイト定義がマシン上に存在しないためです。

では、質問に戻ると、「SharePointサイトテンプレートはサイト定義よりもパフォーマンスが低いのですか？」私の答えは次のとおりです。「サイトの定義またはサイトテンプレートを使用するかどうかの決定において、パフォーマンスに関する考慮事項が役割を果たすべきではありません。機能的な目的があるべきです」今では議論の余地がありますが、私にとっては、機能の作成よりもサイト定義を選択する理由はほとんどありません。

「ゴースト」に関する限り、行く。ええ、カスタマイズしたページはデータベースに保存されます。そして、それを取得するためにデータベースを往復する必要があります。しかし、SharePointは賢明ですが、もちろんこれをキャッシュします。したがって、理論的には、実際には誰も気づかないほど遅くなります。

ゴーストは2003年から製品に組み込まれており（おそらくそれ以前のSTSで、覚えていない）、パフォーマンスへの影響に関する公式のガイダンスを見たことがありません。コメント。

これは、私はそれが本当に心配していないと信じるように導きます。 「ゴースト」に関する大きな懸念ページを維持するのは困難ですが、2007年とMasterpagesではこれははるかに小さな問題です。

他のヒント

ゴースト解除の問題は、アップグレードの問題ほどパフォーマンスの問題ではありません。

SPS2003では、ゴースト除去にはパフォーマンス上の欠点がありました。これらの問題の多くはSharePoint 2007で対処されました。1つには、非仮想化ページはSPVirtualPathProviderによって非コンパイルページとして実行されます。これにより、少なくとも最初のページのレンダリングが高速になります。

ゴーストのない本当のキラー（またはカスタマイズ-用語の名前を変更して＆quot; un＆quot ;?を切り替えることを考えた人は誰ですか？;-)は、アップグレードするとき、およびページ、ページレイアウト、マスターページ、コンテンツタイプなどがカスタマイズされます。大規模なカスタマイズを使用してMOSSサイトの化粧品のアップグレードを試みたことがある場合、カスタマイズされたページに含まれるレイアウトや機能を失うことなく、すべてを新しいデザインで表示するのが大変なこともわかります。

hth アンダースラスク

サイト定義は、テンプレートがデータベースに保存され、ページがレンダリングされるたびにコンパイルおよび実行する必要があるかどうかに関係なく、ファイルシステムにキャッシュされるため、パフォーマンスが向上します。また、カスタムサイト定義は、既存のサイトテンプレートに基づくテンプレートとは異なり、アップグレードに依存しません。

このブログ投稿およびこの更新されたもの。

ここでの問題はゴーストと呼ばれます。すぐに使用できるSharePointサイトには、SharePoint Webサイトの12のハイブに多数のファイル（マスターページとページレイアウトを含む）が保存されています。これらのファイルに対して要求が行われると、SharePointはディスク読み取り操作を実行できるほどスマートになります。

「ゴースト解除」が可能です。これらのページ。基本的に、ファイルシステムではなくSharePointコンテンツデータベースに格納されているページに変更を加えます。ゴースト化されていないページをリクエストすると、データベースのラウンドトリップが発生します（データベースから選択、ファイルのバイト数を返すなど）。これは必然的に余分な作業の重要な結果になります。サイトにアクセスする数百または数千のユーザーについて話している場合、このデータベースの往復はパフォーマンスの問題になります。

したがって、頻繁に使用されるWebサイトのSharePointカスタムサイト定義は、Webサーバーのファイルシステムにできるだけ多くのファイルを保存します（そして、他のものすべてから...をキャッシュします）。サイト定義は、必ずしもファイルシステムに保存されるわけではありませんが、プロセス（非常に複雑なことは別として）により、カスタマイズされたアイテムの保存場所をはるかに制御できます。

この問題について話している2つのブログの例。 http://itfootprint.wordpress.com / 2007/04/18 / sharepoint-site-template-vs-site-definition / http://my.advisor.com/doc/17614

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top