Sind SharePoint-Websitevorlagen wirklich weniger effizient als Websitedefinitionen?

Question

So scheint es in der SharePoint-Blogosphäre, dass jeder nur die gleichen Aufzählungspunkte aus anderen Blogs kopiert und fügt. Ein Aufzählungspunkt ist, dass SharePoint-Websitevorlagen weniger effizient sind als Websitedefinitionen, da Websitedefinitionen im Dateisystem gespeichert sind. Ist das wahr?

Es scheint seltsam, dass Website-Vorlagen weniger effizient sind. Ich gehe davon aus, dass der gesamte Website-Content in einer Datenbank gespeichert ist, unabhängig davon, ob Sie eine Websitevorlage oder eine Websitedefinition verwenden. Eine Websitevorlage wird einmal auf die Datenbank angewendet, und von nun an sollte es der Website egal sein, ob der Inhalt mithilfe einer Websitevorlage erstellt wurde oder nicht.

Aus welchem ​​Grund ist eine Websitevorlage weniger effizient als eine Websitedefinition?

---

Edit: Links zu den Blogs, die sagen, es ist ein Unterschied in der Leistung:

• Von MSDN: Weil es langsam Vorlagen in speichern und abrufen, um sie von der Datenbank, Website-Vorlagen in Folge haben können langsamere Leistung.
• Von DevX: Benutzervorlagen in SharePoint können jedoch zu Leistungsproblemen führen und sind möglicherweise nicht der beste Ansatz, wenn Sie versuchen, eine Reihe wiederverwendbarer Vorlagen für eine gesamte Organisation zu erstellen.
• Von IT Footprint: Da Vorlagen nur langsam in der Datenbank gespeichert und abgerufen werden, können Websitevorlagen zu einer langsameren Leistung führen. Vorlagen in der Datenbank werden jedes Mal kompiliert und ausgeführt, wenn eine Seite gerendert wird.
• Von Branding SharePoint: Benutzerdefinierte Websitedefinitionen haben die folgenden Vorteile gegenüber benutzerdefinierten Vorlagen:
  • Daten direkt auf dem Webserver gespeichert sind, so dass Leistung ist in der Regel besser.

Zumindest glaube ich, dass die oben genannten Artikel unvollständig sind, und ich denke, einige sind irreführend, auf das, was ich weiß, von Sharepoint-Architektur.

Ich las einen anderen Blogbeitrag, der gegen die Leistungsunterschiede argumentierte, aber ich kann den Link nicht finden.

Answer 1

Die Auswirkungen auf die Leistung der Verwendung von Website-Templates im Vergleich Site-Definitionen ist in der Regel zu hoch angesetzt.

Warum?

Nun, lässt dieses Beispiel nehmen:

1. Sie nehmen eine Teamwebsite Site-Definition.
2. Sie speichern es als neue Site-Vorlage
3. Sie erstellen dann ein neues Sub-Web basierend auf dieser neuen Site-Vorlage.

Was haben Sie? Nun, es ist wichtig, sich daran zu erinnern, dass "Ghosting" auf der PAGE-Ebene, NICHT auf der SITE-Ebene stattfindet. Da Sie KEINE Seiten angepasst haben, kommen alle Seiten, auf die Sie zugreifen, immer noch direkt aus der Site-Definition direkt vom Dateisystem.

Wollen Sie es beweisen, sind hier zwei Tests:

Erster Test

1. Versuchen Sie, die Seite default.aspx in der ursprünglichen Site-Definition zu ändern.
2. Überprüfen Sie Ihre Websitevorlage, beachten Sie, dass die Änderung angezeigt wird.
3. Sein Create "Ghosted" auf das Dateisystem

Zweiter Test

1. noch eine neue Website-Definition.
2. Erstellen Sie eine neue Site basierend auf dieser neuen Site-Definition.
3. Erstellen Sie eine neue Websitevorlage
4. Senden Sie die Websitevorlage an einen Partner mit SharePoint und bitten Sie sie, ein neues Unterweb basierend darauf zu erstellen.

Es wird fehlschlagen. Warum? Weil die Site-Definition auf ihrem Computer nicht existiert.

Um auf Ihre Frage zurückzukommen: "Sind SharePoint-Websitevorlagen wirklich weniger leistungsfähig als Websitedefinitionen?" Meine Antwort wäre: "Leistungsaspekte sollten bei Ihrer Entscheidung, eine Site-Definition oder eine Site-Vorlage zu verwenden, keine Rolle spielen, das funktionale Ziel, das Sie haben sollten". Jetzt wird es umstritten, aber für mich gibt es sehr wenige Gründe, sich für die Erstellung einer Site-Definition zu entscheiden.

Soweit "Ghosting" geht. Yup, wenn angepasst Ihre Seite in der Datenbank gespeichert wird, und yup, müssen Sie eine Datenbank Rundreise machen, um es zu bekommen. Aber, intelligent, dass es ist, wird das natürlich zwischenspeichern. Also, in der Theorie, yup es langsamer, in der Praxis bemerkt niemand wirklich.

Ghosting ist in dem Produkt seit 2003 (wahrscheinlich in STS davor, nicht daran erinnern) und ich habe noch nie eine offizielle Anleitung über die Auswirkungen auf die Leistung gesehen, noch jemand spekuliert über die "es ist langsamer" Kommentare.

Dies führt zu der Annahme, dass es sich nicht wirklich Sorgen macht. Die größere Sorge mit "Ghosted" -Seiten ist die Schwierigkeit, die mit der Pflege dieser Seiten verbunden ist, aber mit 2007 und Masterpages ist dies ein viel kleineres Problem.

Answer 2

Site-Definitionen sind leistungsfähiger, da sie im Dateisystem zwischengespeichert werden, ob Vorlagen in der Datenbank gespeichert sind und jedes Mal kompiliert und ausgeführt werden müssen, wenn eine Seite gerendert wird. Außerdem sind benutzerdefinierte Websitedefinitionen unabhängig von der Aktualisierung, im Gegensatz zu Vorlagen, die auf einer vorhandenen Websitevorlage basieren.

Es gibt weitere Unterschiede, die in this blog post und this updated one gut dargestellt sind.

Answer 3

Das Problem hier heißt Ghosting. Eine Out-of-the-Box-SharePoint-Website speichert viele Dateien (einschließlich Masterpages und Seitenlayouts) in der 12-Stock-Struktur der SharePoint-Website. Wenn für diese Dateien eine Anforderung gestellt wird, ist SharePoint intelligent genug, um eine Datenträgerleseoperation auszuführen.

Es ist möglich, diese Seiten zu deaktivieren. Im Wesentlichen erstellen Sie eine Änderung an der Seite, die in der SharePoint Conent-Datenbank anstelle des Dateisystems gespeichert ist. Eine Anfrage für eine Un-Ghosted-Seite führt zu einem Datenbank-Umlauf (Auswahl aus der Datenbank, Rückgabe der Bytes der Datei usw.). Dies führt zwangsläufig zu einer nicht unerheblichen Menge an zusätzlicher Arbeit.Wenn Sie von 100 oder 1000 Benutzern auf der Website sprechen, wird diese Datenbankrundfahrt zu einem Leistungsproblem.

So eine benutzerdefinierte SharePoint-Website-Definition für eine stark frequentierte Website möchten so viele Dateien auf dem Dateisystem des Webservers wie möglich speichern (und die .... aus allem anderen zwischenspeichern). Eine Standortdefinition wird nicht notwendigerweise im Dateisystem gespeichert, aber der Prozess (abgesehen davon, dass er viel komplexer ist), bietet eine weitaus größere Kontrolle über den Speicherort von benutzerdefinierten Elementen.

Ein Beispiel von zwei Blogs, die über das Problem sprechen. http://itfootprint.wordpress.com/2007/04/18/sharepoint-site-template-vs-site-definition/ http://my.advisor.com/doc/17614

Answer 4

Das Problem mit der Unghosting-Funktion ist nicht so sehr ein Leistungsproblem als ein Upgrade-Problem.

In SPS2003 hatte die Unghosting-Funktion einen Leistungsnachteil. Ein Großteil dieser Probleme wurde in SharePoint 2007 behoben. Zum einen werden die nicht-gehosteten Seiten von SPVirtualPathProvider als nicht kompilierte Seiten ausgeführt - dies ergibt zumindest für die erste Seite ein schnelleres Rendering.

Der wahre Killer mit un-Ghosting (oder Customizing - wer dachte schon, es ist eine gute Idee, sowohl den Begriff zu ändern und auch das "un"?) Ist, wenn Sie aktualisieren möchten, und Ihre Seiten, Seite Layouts, Masterseiten, Inhaltstypen usw. werden angepasst. Wenn Sie jemals versucht haben, ein kosmetisches Upgrade einer MOSS-Site mit umfangreichen Anpassungen durchzuführen, wissen Sie auch, wie schwer es ist, alles zu bekommen, um das neue Design zu zeigen, ohne das Layout oder die Funktionalität der angepassten Seiten zu verlieren.

hth Anders Rask