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

Question

Quindi, nella blogosfera di SharePoint sembra che tutti copino e incollino gli stessi punti elenco da altri blog. Un punto elenco che ho visto è che i modelli di sito di SharePoint sono meno efficienti delle definizioni del sito perché le definizioni del sito sono archiviate nel file system. È vero?

Sembra strano che i modelli di sito siano meno efficienti. Comprendo che tutto il contenuto del sito risiede in un database, sia che si utilizzi un modello di sito o una definizione del sito. Un modello di sito viene applicato una volta al database e da allora in poi il sito non dovrebbe preoccuparsi se il contenuto è stato creato utilizzando un modello di sito o meno.

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

---

Modifica: collegamenti ai blog che indicano una differenza di prestazioni:

• Da MSDN : poiché è lento archiviare i modelli in e recuperarli dal database, i modelli di sito possono causare prestazioni più lente.
• Da DevX : Tuttavia, i modelli utente in SharePoint possono portare a prestazioni problemi e potrebbe non essere l'approccio migliore se stai cercando di creare una serie di modelli riutilizzabili per un'intera organizzazione.
• Da Footprint IT : Poiché è lento archiviare i modelli e recuperarli dal database, i modelli del sito possono comportare prestazioni più lente. I modelli nel database vengono compilati ed eseguiti ogni volta che viene eseguito il rendering di una pagina.
• Da SharePoint branding : le definizioni personalizzate del sito contengono seguenti vantaggi rispetto ai modelli personalizzati:
  • I dati vengono archiviati direttamente sui server Web, pertanto le prestazioni sono in genere migliori.

Come minimo, penso che gli articoli precedenti siano incompleti e penso che molti siano fuorvianti in base a ciò che so dell'architettura di SharePoint.

Ho letto un altro post sul blog che discuteva delle differenze di prestazioni, ma non riesco a trovare il link.

Answer 1

L'impatto sulle prestazioni dell'uso dei modelli di sito rispetto alle definizioni del sito è generalmente sopravvalutato.

Perché?

Bene, prendiamo questo esempio:

1. Prendi una definizione del sito del sito del team.
2. Lo salvi come nuovo modello di sito
3. Quindi creare un nuovo Web secondario basato su questo nuovo modello di sito.

Che cosa hai? Bene, la cosa importante da ricordare è che "Ghosting" accade a livello di PAGINA, NON a livello di SITO. Poiché non hai personalizzato QUALSIASI pagina, tutte le pagine a cui accedi accedono comunque direttamente dalla definizione del sito, direttamente dal filesystem.

Vuoi provarlo, ecco due test:

Primo test

1. Prova a modificare la pagina default.aspx nella definizione del sito originale.
2. Controlla il modello del tuo sito, nota che vedi la modifica.
3. È ancora " Ghosted " al filesystem

Secondo test

1. Crea una nuova definizione del sito.
2. Crea un nuovo sito basato su questa nuova definizione del sito.
3. Crea un nuovo modello di sito
4. Invia il modello del sito a un compagno con SharePoint e chiedi loro di creare un nuovo Web secondario basato su di esso.

Fallirà. Perché? Perché la definizione del sito non esiste sul proprio computer.

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

Per quanto riguarda " Ghosting " va. Sì, quando la tua pagina personalizzata verrà archiviata nel database, e sì, dovrai fare un viaggio di andata e ritorno per ottenere il database. Ma SharePoint, per quanto intelligente, ovviamente lo memorizzerà nella cache. Quindi, in teoria, sì, è più lento, in pratica, nessuno se ne accorge davvero.

Ghosting è stato nel prodotto dal 2003 (probabilmente in STS prima di allora, non ricordo) e non ho mai visto una guida ufficiale sull'impatto sulle prestazioni che ha, né nessuno speculare oltre "è più lento" Commenti.

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

Answer 2

Il problema con il non-brinamento non è tanto un problema di prestazioni quanto un problema di aggiornamento.

In SPS2003 lo svuotamento ha avuto un inconveniente nelle prestazioni. Molti di questi problemi sono stati risolti in SharePoint 2007. Per prima cosa, le pagine non fantasma vengono eseguite come pagine non compilate da SPVirtualPathProvider, che in realtà fornisce un rendering più veloce almeno per la prima pagina.

Il vero killer con un-ghosting (o personalizzazione -che mai pensato sia una buona idea sia per rinominare il termine sia per cambiare il " un " ;? ;-) è quando vuoi aggiornare, e le tue pagine, pagina layout, pagine mastro, tipi di contenuto ecc. sono personalizzati. Se hai mai provato a fare un aggiornamento cosmetico di un sito MOSS con ampia personalizzazione, sai anche che dolore è avere tutto per mostrare il nuovo design, senza perdere il layout o la funzionalità contenuti nelle pagine personalizzate.

hth Anders Rask

Answer 3

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

Esistono altre differenze ben delineate in questo post sul blog e questo aggiornato .

Answer 4

Il problema qui si chiama Ghosting. Un sito di SharePoint pronto all'uso archivia molti file (tra cui pagine master e 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, creare una modifica alla pagina archiviata nel database conent di SharePoint anziché nel file system. Una richiesta per una pagina non fantasma comporterà un round trip di database (selezione dal database, restituzione dei byte del file, ecc.). Ciò comporta necessariamente una quantità non banale di lavoro extra. Quando parli di 100 o 1000 utenti che colpiscono il sito, questo round trip del database diventa un problema di prestazioni.

Quindi una definizione di sito personalizzata di SharePoint per un sito Web molto utilizzato vorrà archiviare quanti più file possibili sul file system del server Web (e memorizzare nella cache il .... di tutto il resto). Una definizione del sito non è necessariamente memorizzata nel file system, ma il processo (oltre ad essere molto più complesso) offre un controllo molto maggiore della posizione di archiviazione di tutti gli elementi personalizzati.

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