sábado, 10 de enero de 2009

Modificar la apariencia de nuestro sitio

Continuando con el hilo de los post anteriores “Quick reference Sharepoint” hablaremos ahora de una de las cosas que tendremos que hacer tarde o temprano en un proyecto con Sharepoint, modificar la apariencia de nuestro sitio.

Sharepoint nos proporciona varios mecanismos que aprovechan la infraestructura de ASP.NET 2. : Los temas, masterpages, las colecciones de hojas de estilo y de imágenes, los elementos de navegación.

Masterpage

Las masterpages consisten en plantillas que definen cómo se distribuirá el contenido en una página pero sin llegar a conocer el contenido ni su comportamiento. Sharepoint nos proporciona varias masterpage en función del tipo de plantilla de sitio que elijamos.

Para alojar los ficheros masterpage disponemos de una galería por cada colección de sitios, lo podemos encontrar en la conficugarción del sitio raíz en la opción “Páginas maestras” o en la ruta “/_catlagos/masterpage/”.

Si abrimos Sharepoint Designer y observamos la página default.aspx, veremos cómo está haciendo referencia a la masterpage por defecto mediante la url “~masterurl/default.master”. El path “~masterurl” indica el path a la galería de páginas maestras.

<%@ Page language="C#" MasterPageFile="~masterurl/default.master" Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage,Microsoft.SharePoint,Version=12.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c" meta:webpartpageexpansion="full" meta:progid="SharePoint.WebPartPage.Document" %>

En el siguiente artículo encontramos la distribución de cada uno de los contentplaceholder de la masterpage por defecto: Default content placeholders in a SharePoint master page

Provisionando una masterpage

Para modificar una masterpage tenemos varios mecanismos:

· Convirtiendo el fichero en unghosted

· Provisionando la masterpage en la galería de páginas maestras.

· Alojando la masterpage en la definición de la plantilla de sitio

· Desde una feature

Convirtiendo el fichero en unghosted

Esta es la manera más fácil y rápida, consiste en crear una instancia del fichero en la bbdd de contenidos de manera que en lugar de instanciarse desde el sistema de ficheros del frontal se instancia a partir de la bbdd de contenidos.

Esta es una práctica poco recomendable para implantaciones serias, solo las utilizaremos en prototipos. En el artículo Ghosted o unghosted, ¿Quien corre mas? podéis encontrar los motivos por los que no son recomendables las ficheros unghosted.

Provisionando la masterpage en la galería de páginas maestras.

Consiste en cargar un fichero masterpage directamente en la galería de páginas maestras. Esta galería consiste euna librería de documentos , por lo quela podremos provisionar manualmente o mediante features o código.

Alojando la masterpage en la definición de la plantilla de sitio

Consiste en definir una masterpage para todos los sitios que se creen a partir de una plantilla, de manera que no haya que subirla manualmente en cada colección.

En el siguiente artículo encontramos un tutorial acerca de cómo hacerlo: How to Create and Store Master Pages on the Server for Use with Site Collections

Desde una feature

Para provisionarlo desde una feature:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="
http://schemas.microsoft.com/sharepoint/">
    <Module Name="AddMasters" Url="_catalogs/MasterPage" >
        <File Url="MyDefault.master" Type="GhostableInLibrary"
          IgnoreIfAlreadyExists="True">

        </File>
        <File Url="custom.master" Type="GhostableInLibrary"
          IgnoreIfAlreadyExists="True"/>

        </File>
  </Module>
</Elements>

Podemos encontrar un ejemplo en: Create a Feature: Master Pages for Site Collections

Establecer la masterpage

A la hora de provisionar los ficheros debemos pensar que cada sitio tiene su propia galería de páginas maestras, por lo que podemos hacer que cada sub-sitio tenga su propia apariencia.

Para establecer la masterpage por defecto del sitio podemos o bien indicarlo con Sharepoint Designer seleccionando el fichero y con el botón derecho “Establecer como página principal predeterminada”, o bien utilizando Sharepoint Manager seleccionando el sitio y editando la propiedad “CustomMasterUrl”.

Mediante programación podemos hacer lo siguiente:

CurrentWeb.MasterUrl = "/_catalogs/masterpage/MyDefault.master";
CurrentWeb.CustomMasterUrl = "/_catalogs/masterpage/custom.master";
CurrentWeb.Update();

Si tenemos habilitada la característica de publicación

Dispondremos de funcionalidades adicionales que nos facilitarán el mantenimiento de estilos en una jerarquía de sitios grande.

Dispondremos de la opción “Página maestra” en la página de configuración del sitio en la sección “Aspecto”, desde donde podremos establecer la masterpage por defecto. Además disfrutaremos de la posibilidad de herencia de de manera que se apliquen los cambios a todos los subsitios.

Distribución de contentplaceholder

Cuando hagamos personalizaciones que cambien drásticamente la apariencia lo más fácil es mantener los placeholders estándar para que no se produzca ningún error inesperado, pero los podremos mantener ocultos mediante la propiedad “visibility”.

Masterpage de Application pages

Las páginas del tipo Application pages no podrán utilizar la masterpage default.master. Por defecto utilizan Application.master alojada en la ruta “_layout”.

Hojas de estilo

Sharepoint utiliza por defecto la hoja de estilos CORE.css en el directorio “12\Templates\Layouts\{Idioma}\Styles”. No es recomendable editar directamente este fichero ya que es bastante complejo, es común para todos los sitios y puede que se pierdan los cambios al instalar actualizaciones.

Para establecer nuestras propias hojas de estilo podremos indicarlo mediante el tag de la masterpage “<SharePoint:CssLink>”. Podemos establecer distintas hojas de estilo mediante este elemento y su propiedad “DefaultUrl” donde indicaremos la url de nuestra hoja de estilo.

<SharePoint:CssLink runat="server" DefaultUrl="<% $SPUrl:~SiteCollection/_layouts/styles/prueba.css%>" />

También podemos especificar más hojas de estilos mediante el uso de “<SharePoint:CssRegistration>” que registrará las hojas de estilo en orden alfabético antes de renderizar las hojas primarias, por defecto y altérnate.

En el siguiente artículo podemos encontrar una completa referencia sobre los estilos por defecto: CSS Reference Chart for SharePoint 2007

Si tenemos habilitada la característica de publicación

Desde la opción “Página maestra” en la sección “Aspecto” de la página de configuración del sitio podremos indicar nuestros propios ficheros de hoja de estilo sin tener que modificar la masterpage y podremos aplicarlo a todos los subsitios.

Dispondremos además una librearía de hojas de estilo donde almacenar nuestras css y poder establecerlas en la opción mencionada anteriormente.

Desde la masterpage también podremos utilizar los elementos “<SharePoint:CssLink>” y “<SharePoint:CssRegistration>” pero indicando en la url que utilice las hojas de estilo de la galería de estilos.

<SharePoint:CssRegistration name=”<% $SPUrl:~SiteCollection/Style Library/~language/Core Styles/ prueba.css%>” runat=”server”/>

Temas

Nos permiten cambiar la apariencia de nuestros sitios sin cambiar la distribución ni realizar modificaciones en las páginas. Los temas permiten cambiar el estilo, los colores y las imágenes asociadas a los estilos.

Para cambiar el tema de nuestro sitio podremos realizarlo desde el navegador en la opción “Tema del sitio” en la página de configuración del sitio.

Para crear nuevos temas podemos fijarnos de los existentes y extenderlos o adaptarlos. En la carpeta “12\Template\themes” estarán alojados todos los temas disponibles. Copiais una carpeta de un tema existente y lo renombráis pero en mayúsculas. Dentro existirá un fichero con extensión “.inf” lo renombrais (también en mayúsculas” con el mismo nombre que la carpeta que habéis creado. Abrís el fichero “.inf” y modificáis los títulos.

A continuación ya podéis editar vuestro tema incluyendo imágenes y hojas de estilo.

Una vez terminado tendréis que registrar el estilo en el fichero “\12\TEMPLATE\LAYOUTS\{Idioma}\SPTHEMES.XML”.

En el siguiente enlace podréis encontrar un ejemplo más detallado: http://www.sharepointblogs.com/tigirry/archive/2007/07/03/custom-site-theme-for-sharepoint-2007-moss-2007-and-wss-3-0.aspx

miércoles, 7 de enero de 2009

Habilitar intellisense para Xml de definición de Sharepoint

Uno de los problemas que nos encontramos al desarrollar componentes para Sharepoint es que no disponemos de una herramienta gráfica completa para definirlos, de manera que tenemos que ser nosotros los que editemos manualmente los xml de definición de nuestras features, contentypes, esquemas, etc...

Utilizaremos la ayuda de intellisense de Visual Studio para componer estos Xml’s. Para habilitarlo abriremos nuestro xml y en la ventana de propiedades en la propiedad “Schemas” seleccionaremos el icono de más detalle “…”.

Al seleccionarlo se abrirá una ventana con los esquemas predefinidos para el esquema “http://schemas.microsoft.com/sharepoint “.

A continuación dejaremos solo el fichero wss.xsd alojado en el directorio de sharepoint “Template\xml\wss.xsd”. Para desmarcar los ficheros seleccionaremos el valor “Automatic” en la columna “Use”.

Una vez seleccionado aceptamos las modificaciones y ya podremos disfrutar de la ayuda de Microsoft para completar nuestro xml.

lunes, 5 de enero de 2009

Novedades en Windows SharePoint Services 4.0?

Recientemente Michael Greth ha publicado dos post donde nos comenta algunas de las novedades que incorporará WSS 4.

Custom List Views and WSS 4.0’s XSLT-based List View

Custom Field Types and WSS 4.0’s XSLT-based Field Type

Según comenta Michael Greth, Microsoft ha publicado varios artículos (The CustomListView rule in Pre-Upgrade Checker can warn that customized list views that will not be upgraded y La regla CustomFieldType en Comprobador previas a la actualización en el Service Pack 2 de Windows SharePoint Services 3.0 puede advertir que campo personalizado no se actualizarán tipos) acerca de posibles errores con los list view y algunos customfields al actualizar a la nueva versión de Sharepoint Service.

De estos artículos Michael saca las siguientes conclusiones acerca de la siguiente versión WSS 4:

  • El List View WebPart evoluciona a una nueva versión XSLT-based List View Web Part con nuevas funcionalidades como la mejora en la personalización con Sharepoint Designer, formatos condicionales y mejoras en la experiencia del desarrollo con XSLT.
  • Aparecerá un nuevo tipo de campo llamada XSLT-based field type.

Bueno, veremos que pasa en estos meses que llegan, lo que si es seguro es que todos estamos deseando tener en nuestras manos la nueva versión.

lunes, 29 de diciembre de 2008

Operaciones con Stsadm

Siguiendo con el hilo del post anterior para ayudar en la introducción con Sharepoint, os dejo un enlace con las operaciones que se pueden realizar con Stsadm por categorías, creo que os será más útil que enumeradas alfabéticamente.

http://technet.microsoft.com/en-us/library/cc262643.aspx

Definir Lookup Site Columns desde una Feature

Otra de las sorpresas que nos guarda Sharepoint son los campos lookup. Los campos lookup nos permiten tener desde las listas referencia a valores de otra listas. El problema viene cuando queremos crear una feature que contenga un tipo de campo Lookup para poder exportarlo a otro entorno. Esto se debe a que la definición de este tipo de campos lleva asociada el GUID de la lista y el GUID del web site donde se aloja, por lo que al exportarlo a una colección distinta no podremos hacerlo ya que la instancia de la lista de referencia tendrá un GUID distinto.

Googleando un poco he encontrado varias soluciones a esta carencia de sharepoint:

  • Definición del campo a nivel de lista en lugar de un site column
  • Creando un Feature Receiver que recalcule el id de la lista de referencia

Definición del campo a nivel de lista en lugar de un site column

Según algunas referencias de internet (http://blogs.msdn.com/joshuag/archive/2008/03/14/add-sharepoint-lookup-column-declaratively-through-caml-xml.aspx) en lugar de indicar el GUID de la lista en el campo "List", podemos indicar la URL de la lista. Lo malo es que lo que no dicen es que esto no funciona con los site column's, ya que solo es válido para columnas que definamos asociados a la propia lista.

Creando un Feature Receiver que recalcule el id de la lista de referencia

Consiste en recalcular el GUID de la lista de referencia al activar la característica.

Crearemos nuestro site column de forma normal y en la propiedad "List" indicaremos el nombre de la lista (no url). Esto hará que se cree el site column pero con una referencia errónea, por lo que al intentar utilizarlo nos dará un error al no encontrar la lista. Por lo que asociaremos a nuestra feature un FeatureReceiver que busque el guid de la lista en el sitio donde se está creando y lo reasigne al campo.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/>
<Field Type="Lookup"
DisplayName="Locations"
Required="FALSE"
List="LocationsList"
ShowField="LinkTitleNoMenu"
UnlimitedLengthInDocumentLibrary="FALSE"
Group="COBDemo"
ID="{6F26090A-C2AE-44d7-8F70-EE1663FE29F1}"
SourceID="{8c066b26-5a3e-4e1b-85ec-7e584cf178d7}"
StaticName="Locations"
Name="Locations"
/>
</Elements>

<Feature xmlns="http://schemas.microsoft.com/sharepoint/ Id="B188E645-F989-4baa-A109-D2313648432E"
Title="COB.Demo.ListBasedSiteColumns"
Description="Creates one of more site columns which get their data from lists (lookup fields).
The main definition of the columns is in CAML schema, but a feature receiver is used to fix up
the reference to the list. Both the feature and assembly deployment (to the GAC) are handled by COB.Demo.ListBasedSiteColumns.wsp."
Scope="Site" Hidden="FALSE"
Version="1.0.0.0"
ReceiverAssembly="COB.Demo.ListBasedSiteColumns, Version=1.0.0.0, Culture=neutral, PublicKeyToken=417a990752680f01"
ReceiverClass="COB.Demo.ListBasedSiteColumns.FeatureReceiver"
>
<ElementManifests>

................
</ElementManifests>
<Properties>
</Properties>
</Feature>

Existe un proyecto en codeplex SP2007LookupFields que implementa el FeatureReceiver que lo hace por nosotros. Solo tenéis que descargarlo, instalar el assembly y asociarlo en nuestra Feature.

Aunque existe otra solución que mejora SP2007LookupFields que hace que no tengas que indicar la ruta del fichero xml con la definición: http://mexicanratdog.wordpress.com/2007/10/01/create-lookup-site-columns-target-lists-through-a-feature/ ,en este ejemplo utilizan la propia definición de la Feature y buscan todos los campos del Tipo Lookup y les intenta cambiar el valor de la propiedad "List". Muy recomendable !!!

Solo una pequeña cuestión en este proyecto, y es que tiene un pequeño error que hace que se pueda realizar un Dispose sobre el RootWeb, el trozo de código que debéis corregir es el siguiente:

En lugar del código siguiente:

using (currentWeb)

{

........

}

lo sustituiremos por :

try{

.........

}finally{

if (!currentWeb.IsRootWeb)

currentWeb.Dispose();

}

A la hora de modificar el campo lookup desde el FeatureReceiver en ocasiones puede que tengamos problemas al borrar y volver a crear el site column ya que puede que tengamos una instancia y no podamos eliminarla. Para solucionarlo podemos reemplazar el código de la función createLookupColumn por el siguiente basado en el artículo: Field Definition Schema

private void createLookupColumn(SPWeb web, string sColumnDefinitionXml, string sColumnName)

{

SPFieldLookup lookupColumn = (SPFieldLookup)web.Fields[sColumnName];

lookupColumn.SchemaXml = sColumnDefinitionXml;

lookupColumn = (SPFieldLookup)web.Fields[sColumnName];

lookupColumn.LookupWebId = web.ID;

lookupColumn.Update();

}

jueves, 25 de diciembre de 2008

Quick reference Sharepoint

¿Por dónde empiezo?, esta es la respuesta que queremos dar a los consultores que acaban de llegar por primera vez a un proyecto en Sharepoint. Esta guía os servirá para encontrar los recursos básicos y facilitaros el aprendizaje de este producto.

Podéis bajaros el documento original en: http://blogs.renacimiento.com/mcortes/Documentos/Quick%20reference%20Sharepoint.docx

Conceptos

¿Qué es Microsoft Office SharePoint Server?

Primera introducción de Microsoft Office Sharepoint Server 2007

Libro Microsoft SharePoint 2007 UNLEASHED

Libro básico para iniciarnos en Sharepoint Server 2007

TechNet Tech Center for Microsoft Office SharePoint Server 2007

Centro de recursos para Microsoft Office Sharepoint Server 2007

TechNet Tech Center for Windows SharePoint Services 3.0

Centro de recursos para Windows Sharepoint Services 3

Recopilatorio Posts Plataforma SharePoint Blog CIIN

Recopilatorio de enlaces a post acerca de Sharepoint. Aunque en su página los podéis encontrar actualizados

Implementing Microsoft® Office SharePoint® Server 2007 and Windows® SharePoint® Services 3.0 Solutions

Guía de conceptos muy completa

Infraestructuras y Arquitectura

SharePoint Server TechCenter

Portal en TechNet acerca de MOSS2007

Planning and architecture for Office SharePoint Server 2007

Referencia básica acerca de cómo diseñar nuestra implantación

Deployment for Office SharePoint Server 2007

Referencia acerca del despliegue de portales en Sahrepoint.

Biblioteca técnica de Windows SharePoint Services 3.0

Portal en TechNet acerca de Wss3

Backup, Recovery, and Availability Resource Center for SharePoint Server 2007

Portal con recursos y herramientas para el mantenimiento de sistemas Sharepoint

Plan for data protection and recovery

Contiene varias guías para el mantenimiento y restauración de la bbdd de Sharepoint

SharePoint Capacity Planning Tool

Herramienta para ayudarnos a estimar los recursos que necesitaremos para nuestra implantación

Desarrollo

Introduction to SharePoint Products and Technologies for the Professional .NET Developer

Artículo de introducción a la programación sobre MOSS2007. Contiene una gran cantidad de enlaces a otros tutoriales y recursos.

Libro Inside Microsoft Windows SharePoint Services 3.0

Libro imprescindible para desarrollar y entender cómo funciona Sharepoint. Aunque desarrolles con MOSS, debes leer antes este libro.

Contiene ejemplos muy útiles para aplicar en proyectos.

Preparing the development environment

Posta cerca de cómo preparar nuestros entorno de desarrollo con VStudio 2005

Sharepoint Developer Introduction

Portal de inicio con enlaces a ejemplos y recursos

Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0

Introducción al desarrollo en WSS3

Sharepoint Services Developer Center

Portal con recursos para desarrolladores de Wss3

SharePoint Server 2007 Developer Portal

Portal con recursos para desarrolladores de MOSS2007

Windows SharePoint Services 3.0: Software Development Kit (SDK)

SDK para Windows Sharepoint Services 3

SharePoint Server 2007 SDK: Software Development Kit

SDK para Microsoft Office Sharepoint Server 2007

Screencast de MOSS2007 y WSS3

Página con los enlaces para descargar vídeos acerca de MOSS2007 y WSS3

Technical Articles WSS3

Enlaces a artículos técnicos de WSS3 en MSDN

SharePoint Products and Technologies Customization Best Practices

Enlaces a Best Practices en MSDN

patterns & practices SharePoint Guidance

Guía de pattenrs&Practice para el desarrollo en Sharepoint, con ejemplos y enlaces

Patterns&practices en MSDN

Guía de pattenrs&Practice para el desarrollo en Sharepoint

Best Practices: Using Disposable Windows SharePoint Services Objects

Recomendaciones para liberar correctamente los recursos

Best Practices: Common Coding Issues When Using the SharePoint Object Model

Recomendaciones al manejar el modelo de objetos de Sharepoint

Herramientas

Stsadm

Herramienta básica para la gestión de la granja

SharePoint Administration Toolkit

VSeWSS

Extensiones de Sharepoint Para Visual Studio 2008. Imprescindible!!

SharePoint Manager 2007

Herramienta de gestión muy completa. Imprescindible!!!

CAML Query Builder

Herramienta para construir la consultas CAML. Imprescindible!!

EventHandler Explorer

Herramienta para gestionar los EventHandlers de forma visual

Imtech Fields Explorer

Herramienta muy útil para construir features

Comunidades

Sharepoint community Portal

Portal con una gran cantidad de referencias y recursos

SharepointBlogs

Blogs temáticos de Sharepoint, encontrareis las últimas noticias, actualizaciones, recursos, ejemplos, etc.

Blogs renacimiento

Blogs de renacimiento, podéis encontrar a grandes profesionales con gran experiencia en el mundo de Sharepoint

Blogs de Geeks

Blogs de profesionales de todo tipo, hay una gran cantidad de artículos acerca de sharepoint.

Sharepoint User Groups Spain

Portal de usuarios de España

Blog del CIIN

Blog del Centro de Innovación en integración de Navarra. Contiene una gran cantidad de enlaces sobre Sharepoint.

Sharepoint Pedia

Portal con ejemplos y referencias para la gestión y desarrollo en Sharepoint

Certificaciones

MCTS: Microsoft Windows SharePoint Services 3.0 – Application Development

Imprescindible para desarrolladores. Nos permite adquirir los conocimientos básicos.

MCTS: Windows SharePoint Services 3.0 – Configuration

MCTS: Microsoft Office SharePoint Server 2007 – Application Development

MCTS: Microsoft Office SharePoint Server 2007 – Configuration

Microsoft Certified Master: Microsoft Office SharePoint Server 2007

martes, 2 de diciembre de 2008

Ghosted o unghosted, ¿Quién corre más?

Siguiendo con el anterior artículo "Page Templates con ayuda del Sharepoint Designer", he caído en la cuenta de la cantidad de personsalizaciones que se hacen sobre sharepoint sobre entornos de producción sin que seamos conscientes de cómo afecta esto a nuestros sistema.

Esta claro que una personalización para un sitio con una relativa carga de usuarios es incluso hasta aconsejable ya que el coste en desarrollo podría penalizarnos demasiado. Pero si lo que nos estamos planteando es el desarrollo de una página corporativa o extranet, deberíamos tener en cuenta que una gran volumen de usuarios podría provocar una denegación del servicio.

Para ver como afecta al rendimiento la forma de diseñar la solución he estado realizando una serie de pruebas sobre un wss3. Para ello he creado un aplicación web con una colección y dos listas con unos mil elementos y varios campos con valores aleatorios. Una vez creadas las listas, realicé varias pruebas:

  • Una página ghosted, sin editar ni customizar
  • Una página ghosted con edición de contenido
  • Y una página unghosted

La prueba de carga consistía en realizar una consulta a todos los elementos de la lista llamando a AllItems, y después consultar un elemento de la lista distinto en cada test, con un incremento de carga progresivo de 50 usuario cada 30 segundos por un tiempo máximo de 10 minutos. Estas pruebas se han repetido varias veces cada una y reiniciando el servidor en cada paso.

No os fijéis en los resultados numéricos absolutos, sino en las diferencias entre cada escenario. Esto se debe a que las pruebas están realizadas sobre un wss3 contra una bbdd alojada en la misma máquina, por lo que he tenido que bajarle los hilos del workerprocess para que deje tiempo de proceso al SqlServer.


Una página ghosted, sin editar ni customizar


Podemos observar como el proceso se ha comportado relativamente bien hasta el minuto 6'45, donde ha empezado a aumentar el tiempo de respuesta producirse errores de denegación de servicio.También se aprecia como ha conseguido mantener los tiempos de respuesta aun con una carga elevada. Aunque los errores han ido creciendo poco a poco no han adquirido un número elevado teniendo en cuenta que tenía una carga de unos 800 usuarios, por lo que la respuesta a los usuarios sería relativamente aceptable.




Una página ghosted con edición de contenido


Vemos como en este caso los errores de solicitud se empiezan a producir mucho antes, justo a partir del minuto 5'50'' con una carga total de unos 560 usuarios. Además el tiempo de respuesta y los errores han seguido creciendo.



Ya podemos observar como este tipo páginas tiene un rendimiento 30% inferior y una media de solicitudes por segundoinferior al anterior.

Y una página unghosted

En este caso se ha customizado con Sharepoint Designer la página AllItems de la lista y su masterpage.





Este escenario, ha resultado ser muy parecido al anterior pero fijaros que con tiempos de respuesta más elevados y con una carga de cpu muy superior. Si observáis la línea azul (tiempo de respuesta) existe un salto que coincide con la falta de respsuesta del servidor al VisualStudio debido a un consumo elevado..

En este caso ha conseguido un rendimiento aceptable con una carga de unos 600 usuarios, un 25% inferior al primer caso.


Conclusiones

Anque los ejemplos han sido casos muy sencillos, en un entorno real con muchas personalizaciones habríamos visto como la diferencia habría sido mucho mayor. Tener en cuenta además que esto se ha realizado en una granja con un solo servidor, si hubiéramos tenido varios frontales el rendimiento de las páginas ghosted se incrementaría de forma proporcional al incremento de servidores, pero en el caso de las unghosted crecería en una menor medida debido a que la mayor parte del procesamiento se invertiría en consultar la bbdd de contenidos.