Microsoft Premier Support (PFE) Latin America

Este Blog está dedicado a todo aquel interesado en tecnología Microsoft, y con deseos de aprender de la experiencia y vivencias de los PFES de Latinoamerica y del grupo de Incubation Support & Services (ISS)

December, 2011

  • Performance - Memoria Caché en SharePoint 2010

    Saludos comunidad,

    Esta vez vamos a platicar de un tema que en mi experiencia es poco conocido y que los administradores de SharePoint o el equipo de trabajo que colabora con ellos no está pendiente de las problemáticas que pueden enfrentar. Resulta que estuve trabajando en un cliente que por necesidades muy particulares tiene implementado un Portal público en SharePoint usando plantillas de Colaboración en lugar de usar plantillas de Publicación, pero bueno al final no es este el problema, estuvieron teniendo un problema bastante peculiar relacionado a la carga del sitio principal, pues demoraba demasiado al rededor de 30 segundos, pero cuando éste estaba ya cargado todo parecía fluir de una forma bastante rápida y no concordaba con el primer conteo de segundos.

    Los servidores son virtuales y a pesar de que no hubo un plan de capacidades o guías para virtualizar SharePoint existen bastantes recursos para asignar a los servidores, una granja compuesta por 2 WFE y 1 APP y adicional el servidor de base de datos, cada servidor de SharePoint tiene 2 CPU's y 16 GB de RAM, el portal solo contiene información estática y por ahí algunos videos que son extraidos de otra aplicación que se encarga de hacer el procesamiento, no es parte del trabajo que hace SharePoint, el punto es que no había ninguna razón para que la carga del sitio principal demorara tanto.

    Recordemos que SharePoint desde su versión WSS 3.0 maneja 3 tipos de caché: Perfiles de memoria caché de resultados de página, caché de objetos y caché BLOB (Binary Large Objects), cada uno con una función en particular:

    Memoria caché BLOB

              SharePoint Server 2010 proporciona una memoria caché basada en disco que almacena los archivos que usan las páginas web para que se carguen más rápidamente en el explorador y reduce la carga en el servidor de bases de datos cuando usa dichos archivos. Estos archivos se denominan objetos binarios grandes (BLOB) y la memoria caché se denomina memoria caché BLOB. La memoria caché BLOB se almacena directamente en la unidad de disco duro de un equipo servidor front-end web. La primera vez que se llama a una página web, estos archivos se copian de la base de datos a la memoria caché de la unidad de disco duro del servidor y todas las solicitudes posteriores de dichos archivos se atienden desde la memoria caché de la unidad de disco duro del servidor. De forma predeterminada, la memoria caché BLOB está desactivada y debe habilitarse para poder usar la funcionalidad que proporciona. Cuando se habilita la memoria caché BLOB en el servidor front-end web, se reduce la carga del servidor de bases de datos de SharePoint Server 2010 generada por las solicitudes leídas de los exploradores web.

    Nota: El caché BLOB no es obligatorio, solo si existen objetos mutlimedia en el sitio. Si tenemos una granja de varios WFE se recomienda que el caché se aloje en una partición distinta a C y que todos los WFE tengan la misma unidad lógica.

     
     
     

    Perfiles de memoria caché de resultados de página

             La memoria caché de resultados de página almacena el resultado presentado de una página determinada y almacena también distintas versiones de la página almacenada en la memoria caché según los permisos de los usuarios que solicitan la página. La memoria caché de resultados de página se puede configurar en el nivel de la colección de sitios, en el nivel de sitio y para los diseños de página. La memoria caché de resultados de página está desactivada de forma predeterminada.

    La memoria caché de resultados de página usa perfiles de memoria caché que especifican durante cuánto tiempo deben conservarse los elementos en la memoria caché. Es posible especificar diferentes perfiles de memoria caché para usuarios anónimos y autenticados, lo que optimiza el uso de la memoria caché según los métodos de autenticación permitidos en el sitio.

    Y finalmente:

    Memoria caché de objetos

             La memoria caché de objetos reduce la cantidad de tráfico entre el servidor web y la base de datos de SQL mediante el almacenamiento de los objetos, como listas y bibliotecas, configuración de sitios y diseños de página, en la memoria del equipo servidor front-end web. Por consiguiente, las páginas que requieren estos elementos se pueden presentar rápidamente, lo que aumenta la velocidad a la que se entregan las páginas en el explorador del cliente. La memoria caché de objetos está activada de forma predeterminada.

    Para optimizar la memoria caché de objetos de una aplicación web, especifique su tamaño. Si se especifica un número alto, se puede aumentar el rendimiento de algunos sitios de gran tamaño, aunque esto reduce la memoria en cada servidor front-end web. Puede establecer otra configuración para la memoria caché de objetos en el nivel de la colección de sitios.

    Nota: El caché de objetos solo esta disponible en las plantillas de Publicación o bien cuando las características de publicación están habilitadas, por otro lado éste caché requiere de 2 cuentas de usuario para poder habilitarse:  la cuenta de usuario súper del portal y la cuenta de lector súper del portal

     
     

    Conclusión

    Una vez explicado lo anterior en un breve resumen, es importante decir que el caché de objetos de forma por defecto utiliza la cuenta de sistema del sitio y la cuenta NT Authority\Servicio local, pero existen algunos problemas conocidos con esta configuración, problema que este cliente presentó:
     
    A) El primer problema es que algunos elementos se desprotegen para la cuenta del sistema, por lo que cuando se realice una consulta que incluya estos elementos, se devolverá la versión desprotegida del elemento en lugar de la última versión publicada. Esto es un problema debido a que no es lo que un usuario espera que se devuelva, por lo que la memoria caché debe realizar una segunda consulta para recuperar la versión correcta del archivo. Esto tiene un efecto negativo en el rendimiento del servidor en cada solicitud que incluya estos elementos. Se produciría el mismo problema con cualquier usuario que tenga elementos desprotegidos, si la cuenta de dicho usuario se configuró como la cuenta de usuario súper del portal. Por esta razón, las cuentas configuradas como cuenta de usuario súper del portal y cuenta de lector súper del portal no deben ser cuentas que se usan para iniciar sesión en el sitio. Esto garantiza que el usuario no desproteja de forma accidental elementos y ocasiones problemas en el rendimiento.
    B) La cuenta de lector súper del portal predeterminada es NT Authority\Servicio local, que no se resuelve correctamente en una aplicación de la autenticación de notificaciones. Por lo tanto, si la cuenta de lector súper del portal no está configurada explícitamente para una aplicación de autenticación de notificaciones, al buscar las colecciones de sitios en esta aplicación se obtendrá un error de acceso denegado, incluso para el administrador del sitio. Este error se producirá en los sitios que usen cualquier característica que use explícitamente la caché de objetos, como la Infraestructura de publicación de SharePoint Server, la navegación de metadatos, el elemento web de consulta de contenido o la navegación.
     
    Cuando se configuró apropiadamente el caché de objetos y las cuentas se crearon de acuerdo a las mejores prácticas el tiempo de carga se redujó de 30 segundos a 3 segundos, esto debido a las aplicaciones que son mandadas llamar para hacer el rendering de los videos publicados en la página principal.
     
    Tengan mucho cuidado cuando trabajen con la memoria Caché de SharePoint y presten especial atención en el principal objetivo de sus Colecciones de Sitios y Sitios para que utilicen las plantillas apropiadas y la configuración de caché correcta.
    Para mayor referencia sobre los temas expuestos anteriormente consulten:
     
    Cache settings operations (SharePoint Server 2010) - http://technet.microsoft.com/en-us/library/cc261797.aspx
    Configure object cache user accounts - http://technet.microsoft.com/en-us/library/ff758656.aspx
     
    Saludos
  • Performance - SharePoint 2010 Cache

    Hi there SharePoint community,

    This time let's talk about a particular topic that in my experience is not well known and SharePoint Administrators or SharePoint tem in general is not aware of the issues they can face. I was working recently in a SharePoint RAP where a customer wanted to discuss a performance issues, because of a specific business needs this customer deployed SharePoint using Collaboration site definitios rather than Publishing ones even though their SharePoint is used for a public Portal only, at the end of the day this is not the problem, they were suffering for 2 days because of the main SharePoint page took around 30 seconds to load, once the page was loaded by the explorer the navigation were fast, so this did not match with the first 30 seconds to load.

    The entire SharePoint farm is virtual and even a capacity plan was not performed or SharePoint virtualization guidelines were not followed, the farm is composed by 2 WFE and 1 APP server and database server, each SharePoint server has 2 CPU's and 16 GB of RAM, public portal has only plain information and some videos which use external streaming applications, is not workload for SharePoint, the point is there was not a reason of the slow performance.

    We have to remember that SharePoint since WSS 3.0 version has 3 types of cache, page output cache profiles, object cache and BLOB (Binary Large Objects), each one of them with a specific task:

    BLOB cache

              SharePoint Server 2010 provides a disk-based cache that stores files that are used by Web pages to help them load quickly in the browser, and reduces the load on the database server when it uses those files. These files are known as binary large objects (BLOBs), and the cache is known as the BLOB cache. The BLOB cache is stored directly on the hard disk drive of a front-end Web server computer. The first time that a Web page is called, these files are copied from the database to the cache on the server hard disk drive, and all subsequent requests for those files are then served from the hard disk drive cache of the server. By default, the BLOB cache is OFF and must be enabled to use the functionality it provides. When you enable the BLOB cache on your front-end Web server, you reduce the load on the SharePoint Server 2010 database server created by read requests from Web browsers.

     

    Note: BLOB cache is not mandatory to have it configured, only if multimedia objects are present in sites. If we have a SharePoint farm with more than 1 WFE server it is recommended that BLOB cache is stored in a logical drive different than C drive and every WFE has the same logical unit.

    Page output cache profiles

             The page output cache stores the rendered output of a page. It also stores different versions of the cached page, based on the permissions of the users who are requesting the page. Page output cache settings can be configured at the site collection level, at the site level, and for page layouts. By default, the page output cache is turned OFF.

    The page output cache uses cache profiles that specify how long items should be held in the cache. You can specify different cache profiles to be used for anonymous and authenticated users, which optimizes the use of the cache based on the authentication methods that are allowed on the site.


    Finally:

    Object cache

             The object cache reduces the amount of traffic between the Web server and the SQL database by storing objects—such as lists and libraries, site settings, and page layouts—in memory on the front-end Web server computer. As a result, the pages that require these items are able to be rendered quickly, increasing the speed with which pages are delivered to the client browser. Object cache settings can be configured at the Web application level, and at the site collection level. By default, the object cache is ON at the site collection level.

    You can optimize the object cache for a Web application by specifying the size of the object cache. Specifying a larger number can enhance performance for some large sites at the cost of memory on each front-end Web server. You can configure other settings for the object cache at site collection level.

    Note: Object cache is only available in Publishing SharePoint templates or when publishing features are enabled in your sites, in the other hand object cache requires 2 user accounts:  The Portal Super User and Portal Super Reader accounts

    Conclusion

    After this brief summary, it is important to mention that object cache uses the site system account and NT Authority\Local Service account by default, but there are some known issues with this configuration, issues that this customer faced:
     
    A) The first issue is that some items get checked out to System Account, so when a query that includes these items is made, the checked out version of the item is returned instead of the latest published version. This is a problem because it is not what a user would expect to have returned, so the cache has to make a second query to fetch the correct version of the file. This negatively affects server performance for every request that includes these items. The same problem would occur for any user who has items checked out, if that user’s account was set to be the Portal Super User account. This is why the accounts configured to be the Portal Super User and the Portal Super Reader should not be user accounts that are used to log into the site. This ensures that the user does not inadvertently check items out and cause problems with performance.
     
    B) The default Portal Super Reader account is NT Authority\Local Service, which is not correctly resolved in a claims authentication application. As a result, if the Portal Super Reader account is not explicitly configured for a claims authentication application, browsing to site collections under this application will result in an “Access Denied” error, even for the site administrator. This error will occur on any site that uses any feature that explicitly uses the object cache, such as the SharePoint Server Publishing Infrastructure, metadata navigation, the Content Query Web Part, or navigation.
    Once the object cache was configure properly and user accounts were created and configured according to best practices the main portal page loaded in 3 seconds, some custom application are loaded for video streaming, this does not affect SharePoint since processing is being done externally.
    Be carefull when configure SharePoint to use any type of cache and pay special attention to the main objective for your SharePoint Site Collections or Sites in order to use the correct templates and/or cache configuration.
    To get more information about SharePoint cache please check:
    Cache settings operations (SharePoint Server 2010) - http://technet.microsoft.com/en-us/library/cc261797.aspx
    Configure object cache user accounts - http://technet.microsoft.com/en-us/library/ff758656.aspx
    Untile next time
  • Ha sido éste blog útil?

    Saludos comunidad

    Estamos cerrando el año y nos interesa mucho saber como lo hemos hecho, éste post tiene el simple objetivo de conocer tu opinión acerca del trabajo que hemos estado realizando en el BLOG de PFE, te pedimos a ti ITPRO y comunidad en general que nos des tus comentarios y sugerencias, nos interesa conocer que tipo de información es más valiosa y útil para ti.

    Por favor no dudes en sugerir temas y compartir toda la información que aquí se encuentra con otros colegas.

  • Esse blog tem sido útil?

    Olá Comunidade,

    Fechamos o ano e nos interessa saber sobre o que achou do blog. Este post tem o simples objetivo de conhecer sua opinião sobre o trabalho que temos desenvolvido no Blog de PFE. Pedimos a você de ITPRO e a Comunidade em geral que nos deixe seus comentários e sugestões, permitindo que a gente conheça que tipo de informação é mais valiosa e útil a vocês.

    Por favor não deixe de sugerir temas e compartilhar as informações que aqui se encontram com outros colegas.

     

  • Has this blog useful?

    Hello there,

    We are closing the year and we would like to know if our job over the PFE LATAM Blog has been useful for you, please tell us if posted articles helped to fix or guide you through the issues or challenges you have faced off with Microsoft technologies.

    Do not hesitate if you have suggestions or topics you would like us to talk about.

    Till next year!!