¿Las plantillas de sitios de SharePoint son realmente menos eficientes que las definiciones de sitios?

Question

Por lo tanto, parece que en la blogósfera de SharePoint todo el mundo simplemente copia y pega las mismas viñetas de otros blogs. Un punto importante que he visto es que las plantillas de sitios de SharePoint son menos eficientes que las definiciones de sitios porque las definiciones de sitios se almacenan en el sistema de archivos. ¿Es eso cierto?

Parece extraño que las plantillas de sitios sean menos eficientes. Tengo entendido que todo el contenido del sitio vive en una base de datos, ya sea que use una plantilla de sitio o una definición de sitio. Una plantilla de sitio se aplica una vez a la base de datos, y desde ese momento el sitio no debería importar si el contenido se creó usando una plantilla de sitio o no.

Entonces, ¿cuál es el motivo arquitectónico por el cual una plantilla de sitio sería menos eficiente que una definición de sitio?

---

Editar: Enlaces a los blogs que dicen que hay una diferencia de rendimiento:

• De MSDN: Debido a que es lento para almacenar plantillas en y recuperarlos de la base de datos, plantillas de sitio puede resultar en rendimiento más lento.
• De DevX: Sin embargo, las plantillas de usuario en SharePoint pueden provocar problemas de rendimiento y pueden no ser el mejor enfoque si está intentando crear un conjunto de plantillas reutilizables para toda una organización.
• De IT Footprint: Debido a que es lento almacenar plantillas y recuperarlas de la base de datos, las plantillas de sitio pueden dar como resultado un rendimiento más lento. Las plantillas de la base de datos se compilan y ejecutan cada vez que se procesa una página.
• De Branding SharePoint: definiciones de sitio personalizado tienen las siguientes ventajas sobre las plantillas personalizadas:
  • Los datos se almacenan directamente en los servidores web, por lo que el rendimiento suele ser mejor.

Como mínimo, creo que los artículos anteriores son incompletos, y creo que muchos puedan inducir a error sobre la base de lo que sé de la arquitectura de SharePoint.

Leí otra publicación de blog que argumentó en contra de las diferencias de rendimiento, pero no puedo encontrar el enlace.

Answer 1

El impacto en el rendimiento de la utilización de plantillas de sitio frente Definiciones sitio es generalmente exagerada.

¿Por qué?

Bueno, vamos a tomar este ejemplo:

1. Se toma una definición del equipo del sitio web.
2. Lo guarda como una nueva plantilla de sitio
3. A continuación, crea una nueva sub-web basada en esta nueva plantilla de sitio.

¿Qué tienes? Bueno, lo importante es recordar que el "efecto fantasma" ocurre en el nivel PAGE, NO en el nivel SITE. Como no ha personalizado NINGUNA página, las páginas a las que accede siguen viniendo directamente de la Definición del sitio, directamente desde el sistema de archivos.

¿Quieres probarlo, aquí hay dos pruebas:

primera prueba

1. intente modificar la página Default.aspx en la definición del sitio inicial.
2. Compruebe la plantilla de su sitio, observe que ve la modificación.
3. su todavía "fantasma" en el sistema de archivos

segunda prueba

1. Crear una nueva definición de sitio.
2. Cree un nuevo sitio basado en esta nueva definición del sitio.
3. Cree una nueva plantilla de sitio
4. Envíe la plantilla del sitio a un compañero con SharePoint y pídales que creen un nuevo subweb basado en él.

Fallará. ¿Por qué? Porque la Definición del sitio no existe en su máquina.

Por lo tanto, para volver a su pregunta, "¿Son las plantillas de sitios de SharePoint realmente menos efectivas que las definiciones de sitios?" Mi respuesta sería: "Las consideraciones de rendimiento no deberían desempeñar un papel en su decisión de utilizar una Definición de sitio o una Plantilla de sitio, el objetivo funcional que debe tener". Ahora es controvertido, pero para mí, hay muy pocas razones para optar por una Definición del sitio sobre la creación de Características.

En cuanto a "Fantasma" va. Sí, cuando se personalice su página se almacenará en la base de datos, y sí, tendrá que hacer una ida y vuelta a la base de datos para obtenerla. Pero, SharePoint, inteligente como es, por supuesto guardará esto. Entonces, en teoría, sí es más lento, en la práctica, nadie realmente lo nota.

Ghosting ha estado en el producto desde 2003 (probablemente en STS antes de eso, no lo recuerdo) y nunca he visto una guía oficial sobre el impacto en el rendimiento que tiene, ni nadie especulando más allá de los comentarios "es más lento".

Esto me lleva a creer que simplemente no es realmente preocupante. La mayor preocupación con las páginas "Ghosted" es la dificultad que conlleva mantenerlas, pero luego, con 2007 y Masterpages, este es un problema mucho más pequeño.

Answer 2

Las definiciones de sitios son más efectivas porque se almacenan en caché en el sistema de archivos, independientemente de si las plantillas se almacenan en la base de datos y deben compilarse y ejecutarse cada vez que se procesa una página. Además, las definiciones de sitios personalizados son independientes de la actualización, a diferencia de las plantillas, que se basan en una plantilla de sitio existente.

Hay otras diferencias bien delineadas en this blog post y this updated one.

Answer 3

El problema aquí se llama Ghosting. Un sitio de SharePoint listo para usar almacena muchos archivos (incluidas páginas maestras y diseños de página) en la sección 12 del sitio web de SharePoint. Cuando se realiza una solicitud para estos archivos, SharePoint es lo suficientemente inteligente como para realizar una operación de lectura de disco.

Es posible "desahogar" estas páginas. Básicamente, crear una modificación de la página que se almacena en la base de datos de SharePoint en lugar del sistema de archivos. Una solicitud de una página sin fantasmas dará como resultado una ida y vuelta de la base de datos (seleccionando de la base de datos, devolviendo los bytes del archivo, etc.). Esto necesariamente resulta en una cantidad no trivial de trabajo extra.Cuando habla de 100 o 1000 de usuarios que visitan el sitio, esta base de datos de ida y vuelta se convierte en un problema de rendimiento.

Por lo tanto, una definición de sitio personalizada de SharePoint para un sitio web muy usado querrá almacenar tantos archivos en el sistema de archivos del servidor web como sea posible (y almacenar en caché el .... de todo lo demás). La definición de un sitio no se almacena necesariamente en el sistema de archivos, pero el proceso (además de ser mucho más complejo) proporciona un mayor control de la ubicación de almacenamiento de los elementos personalizados.

Un ejemplo de dos blogs que hablan sobre el tema. http://itfootprint.wordpress.com/2007/04/18/sharepoint-site-template-vs-site-definition/ http://my.advisor.com/doc/17614

Answer 4

El problema con el desahogo no es tanto un problema de rendimiento como un problema de actualización.

En SPS2003, tener un inconveniente de rendimiento no era bueno. Muchos de estos problemas se abordaron en SharePoint 2007. Por un lado, las páginas sin fantasmas se ejecutan como páginas sin compilación por SPVirtualPathProvider, esto en realidad ofrece una representación más rápida, al menos para la primera página.

El verdadero asesino con desvanecimiento (o personalización -quién alguna vez pensó que era una buena idea cambiar el nombre del término y también cambiar el "un"? ;-) es cuando desea actualizar, y sus páginas, página diseños, páginas maestras, tipos de contenido, etc. son personalizados. Si alguna vez intentó hacer una actualización cosmética de un sitio MOSS con una amplia personalización, también sabe lo difícil que es obtener todo para mostrar el nuevo diseño, sin perder el diseño o la funcionalidad contenida en las páginas personalizadas.

hth Anders Rask