I modelli di sito di SharePoint sono davvero meno efficienti delle definizioni di sito?

Question

Quindi, sembra che nella blogosfera di SharePoint tutti si limitino a copiare e incollare gli stessi punti elenco di altri blog. Un punto elenco che ho visto è che i modelli di sito di SharePoint sono meno efficienti delle definizioni dei siti perché le definizioni dei siti sono archiviate nel file system. È vero?

Sembra strano che i modelli di sito siano meno efficienti. È a mia conoscenza che tutto il contenuto del sito risiede in un database, indipendentemente dal fatto che si utilizzi un modello di sito o una definizione del sito. Un modello di sito viene applicato una sola volta al database e da quel momento sul sito non dovrebbe importare se il contenuto è stato creato utilizzando un modello di sito o meno.

Quindi, qual è un motivo architettonico per cui un modello di sito sarebbe meno efficiente di una definizione di sito?

---

Edit: collegamenti ai blog che dicono che c'è una differenza di prestazioni:

• Da MSDN: Perché è lento a memorizzare i modelli di e recuperarli dal database, modelli di sito possono provocare prestazioni più lente.
• Da DevX: Tuttavia, i modelli utente in SharePoint possono portare a problemi di prestazioni e potrebbero non essere l'approccio migliore se si sta tentando di creare un set di modelli riutilizzabili per un'intera organizzazione.
• Da IT Footprint: Poiché è lento archiviare i modelli e recuperarli dal database, i modelli di sito possono comportare prestazioni più lente. I modelli nel database sono compilati ed eseguiti ogni volta che una pagina viene renderizzata.
• Da Branding SharePoint: definizioni di sito personalizzato tengono i seguenti vantaggi rispetto modelli personalizzati:
  • dati sono memorizzati direttamente sui server Web, quindi le prestazioni è tipicamente migliore.

Come minimo, penso che gli articoli di cui sopra sono incompleti, e credo diversi da indurre in errore in base a quello che so di architettura di SharePoint.

Ho letto un altro post del blog che argomentava contro le differenze di rendimento, ma non riesco a trovare il collegamento.

Answer 1

L'impatto sulle prestazioni del sito utilizzando i modelli contro le definizioni di sito è generalmente sopravvalutata.

Perché?

Beh, consente di dare questo esempio:

1. Si prende una definizione della squadra sito Site.
2. Si salva come nuovo Modello di sito
3. Quindi si crea un nuovo Web secondario basato su questo nuovo modello di sito.

Che cos'hai? Bene, la cosa importante da ricordare è che "Ghosting" avviene a livello PAGE, NON a livello SITE. Dal momento che non hai personalizzato QUALSIASI pagina, qualsiasi pagina a cui accedi proviene ancora direttamente dalla definizione del sito, direttamente dal filesystem.

Vuoi provarlo, qui due test:

Primo test

1. provare a modificare la pagina Default.aspx nella definizione del sito originale.
2. Controlla il modello del tuo sito, nota che vedi la modifica.
3. la sua ancora "fantasma" al filesystem

Secondo test

1. Creare una nuova definizione di sito.
2. Creare un nuovo sito basato su questa nuova Definizione sito.
3. Creare un nuovo modello di sito
4. Inviare il modello di sito a un compagno con SharePoint e chiedere loro di creare un nuovo Web secondario basato su di esso.

Fallirà. Perché? Perché la definizione del sito non esiste sulla loro macchina.

Quindi, per tornare alla domanda, "I modelli di sito di SharePoint sono davvero meno performanti delle definizioni dei siti?" la mia risposta sarebbe: "Le considerazioni sulle prestazioni non dovrebbero avere un ruolo nella decisione di utilizzare una definizione del sito o un modello di sito, l'obiettivo funzionale che si dovrebbe avere". Ora è controverso, ma per me ci sono pochissimi motivi per optare per una definizione del sito rispetto alla creazione di funzionalità.

Per quanto riguarda "Ghosting". Sì, una volta personalizzata la tua pagina sarà archiviata nel Database, e sì, dovrai fare un database di andata e ritorno per ottenerlo. Ma, SharePoint, che lo è, lo memorizzerà naturalmente. Quindi, in teoria, è più lento, in pratica, nessuno se ne accorge.

Ghosting è stato nel prodotto dal 2003 (probabilmente nel STS prima che, non ricordo) e non ho mai visto le linee guida ufficiali sull'impatto delle prestazioni che ha, né nessuno speculare al di là dei "è più lento" commenti.

Questo mi porta a credere che non sia proprio preoccupante. La preoccupazione più grande con le pagine "Ghosted" è la difficoltà che deriva dal mantenerle, ma poi, con il 2007 e Masterpages, questo è un problema molto più piccolo.

Answer 2

Le definizioni dei siti sono più efficienti perché sono memorizzate nella cache sul file system, se i modelli sono archiviati nel database e devono essere compilati ed eseguiti ogni volta che una pagina viene visualizzata. Inoltre, le definizioni dei siti personalizzate sono indipendenti dall'aggiornamento, a differenza dei modelli, che si basano su un modello di sito esistente.

Ci sono altre differenze ben delineate in this blog post e this updated one.

Answer 3

Il problema qui è chiamato Ghosting. Un sito di SharePoint pronto all'uso memorizza molti file (incluse le pagine principali e i pagelayout) nell'hive 12 del sito Web di SharePoint. Quando viene effettuata una richiesta per questi file, SharePoint è abbastanza intelligente da eseguire un'operazione di lettura del disco.

È possibile "Un-Ghost" queste pagine. In sostanza, la creazione di una modifica alla pagina archiviata nel database conent di SharePoint anziché nel file system. Una richiesta per una pagina Non-Ghost comporterà un round trip del database (selezionando dal database, restituendo i byte del file, ecc.). Ciò comporta necessariamente una quantità non trascurabile di lavoro extra.Quando si parla di centinaia o migliaia di utenti che colpiscono il sito, questo round trip del database diventa un problema di prestazioni.

Pertanto, una definizione di sito personalizzato SharePoint per un sito Web molto utilizzato vorrà archiviare il maggior numero possibile di file sul file system del server Web (e memorizzare nella cache .... da tutto il resto). Una definizione del sito non è necessariamente memorizzata sul file system, ma il processo (oltre a essere molto più complesso) dà molto più controllo sulla posizione di archiviazione di qualsiasi articolo personalizzato.

Un esempio di due blog che parlano del problema. http://itfootprint.wordpress.com/2007/04/18/sharepoint-site-template-vs-site-definition/ http://my.advisor.com/doc/17614

Answer 4

Il problema con unghost non è tanto un problema di prestazioni quanto un problema di aggiornamento.

In SPS2003 lo svuotamento aveva un inconveniente di prestazioni. Gran parte di questi problemi è stata affrontata in SharePoint 2007. Per prima cosa, le pagine non fantasma vengono eseguite come pagine non compilate da SPVirtualPathProvider - questo dà un rendering più veloce almeno per la prima pagina.

Il vero killer con anti-ghosting (o personalizzazione - chi ha mai pensato che sia una buona idea sia rinominare il termine e anche cambiare il "un"? ;-) è quando si desidera aggiornare, e le pagine, pagina layout, pagine master, tipi di contenuto, ecc. sono personalizzati. Se hai mai provato a eseguire un upgrade cosmetico di un sito MOSS con un'estesa personalizzazione, sai anche quanto sia doloroso ottenere tutto per mostrare il nuovo design, senza perdere il layout o la funzionalità contenuti nelle pagine personalizzate.

hth Anders Rask