Estimación de los requisitos de rendimiento y capacidad para la administración de contenido web en SharePoint Server 2010

 

Se aplica a: SharePoint Server 2010

Última modificación del tema: 2016-11-30

En este artículo se proporciona una orientación acerca de la administración de la capacidad en los sitios de Microsoft SharePoint Server 2010 que tienen habilitada la infraestructura de publicación. Este documento es específico de SharePoint Server 2010 y la información descrita no se aplica a SharePoint Foundation.

En este artículo se describen los siguientes escenarios:

• Un sitio de publicación en Internet: un sitio de presencia corporativa.

  Este tipo de sitio se publica en Internet y permite que los usuarios anónimos de Internet busquen información acerca de una organización. Este tipo de sitio tiene personalización de marca y su contenido está estrictamente controlado.

• Un sitio de publicación en la intranet: un sitio de noticias internas.

  Este tipo de sitio se publica en el ámbito interno de una organización. Sirve principalmente para compartir información con los usuarios autenticados de una organización. La información del sitio puede estar administrada estrictamente, aunque también es posible que algunas áreas se administren en menor grado.

• Un sitio wiki empresarial: un repositorio de conocimientos.

  Un sitio wiki empresarial es un sitio formado por un único conjunto o granja de servidores que crece de forma gradual a medida que los colaboradores crean páginas nuevas y las vinculan a otras páginas que podrían ser ya existentes o no existir todavía. Los sitios wiki empresariales normalmente se publican en el ámbito interno de una organización. Este sitio permite a las personas de una compañía u organización obtener y compartir conocimientos mediante una solución integrada y mejorada por su entorno de SharePoint.

Tras leer este documento, comprenderá los siguientes conceptos:

• El valor métrico clave (rendimiento) que debe maximizar para admitir gran cantidad de operaciones de lectura.

• Varios cuellos de botella posibles que son relevantes para una implementación de SharePoint Server 2010 de administración de contenido web.

• La importancia de la memoria caché de resultados para maximizar el rendimiento.

• El efecto de las operaciones de escritura en la experiencia de lectura del usuario final.

En este artículo:

• Información de requisitos previos

• Método y detalles de las pruebas

• Implementaciones de administración de contenido web

• Optimizaciones necesarias

• Resultados de las pruebas y recomendaciones

• Acerca de los autores

Información de requisitos previos

Antes de leer este documento, asegúrese de que comprende los conceptos clave relacionados con la administración de la capacidad de SharePoint Server 2010. La documentación que se proporciona a continuación le permitirá conocer el método recomendado para administrar la capacidad y le ofrecerá más contexto para ayudarle a hacer un uso eficaz de la información de este documento.

Para obtener información más conceptual sobre el rendimiento y la capacidad que puede servirle para comprender el contexto de los datos de este artículo, vea los siguientes documentos:

• Administración de la capacidad y tamaño de SharePoint Server 2010

• Casos prácticos técnicos de capacidad y rendimiento (SharePoint Server 2010)

Método y detalles de las pruebas

En cada prueba, se extrajeron las variables que pueden existir en la vida real para mostrar recomendaciones específicas. Por lo tanto, es muy importante que supervise y realice pruebas en su propio entorno para asegurarse de que ha escalado correctamente las variables para adaptarlas al volumen de solicitudes previsto. Para obtener más información acerca de los conceptos de la administración de la capacidad, vea Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010.

En este artículo se describe el rendimiento con las características de la colección de sitios, la infraestructura de publicación de SharePoint Server y el almacenamiento en la memoria caché de resultados. Estas características solo están disponibles cuando la infraestructura de publicación de SharePoint Server está habilitada. De manera predeterminada, los portales de publicación tienen esta característica habilitada.

Conjunto de datos

Las pruebas se realizaron con un conjunto de datos que comparte características comunes con implementaciones de administración de contenido web reales. Si bien la carga ha sido constante, se solicitaron distintas páginas. En la tabla siguiente se describe el conjunto de datos que se usó para estas pruebas.

Conjunto de datos

Objeto	Sitio de publicación
Tamaño de las bases de datos de contenido	2,63 GB
Número de bases de datos de contenido	1
Número de colecciones de sitios	1
Número de aplicaciones web	1
Número de sitios	50
Número de páginas	20.000 páginas divididas en 20 carpetas con 1.000 páginas cada una
Composición de las páginas	Páginas de artículo en HTML básico, con referencias a dos imágenes
Tamaño de página	42 KB sin comprimir; 12 KB comprimida
Imágenes	3.000 de 30 KB a 1,3 MB cada una

Se recomienda configurar Internet Information Services (IIS) de modo que siempre comprima los archivos en lugar de conservar la configuración predeterminada de comprimir los archivos de forma dinámica. Al habilitar la compresión dinámica, IIS comprime las páginas hasta que el uso de CPU excede un umbral concreto. En ese momento, IIS deja de comprimir las páginas hasta que el uso disminuya y ya no exceda el umbral. Las pruebas de este artículo se realizaron con la compresión siempre habilitada.

Este conjunto de datos de prueba solo usó características de SharePoint Server 2010 predeterminadas incluidas con el producto. Su sitio probablemente incluye personalizaciones además de estas características básicas. Por lo tanto, es importante que pruebe el rendimiento de su propia solución.

Hardware

La cantidad de servidores web en la granja de servidores varió por prueba, pero su hardware era idéntico. En la siguiente tabla se describe el hardware de los servidores web y de aplicaciones usados durante estas pruebas.

Especificaciones de hardware para los servidores web y de aplicaciones

	Servidor web
Procesadores	2 procesadores de cuatro núcleos a 2,33 GHz
RAM	8 GB
Sistema operativo	Windows Server 2008 de 64 bits
Tamaño de la unidad de SharePoint	300 GB
Número de adaptadores de red	2
Velocidad del adaptador de red	1 gigabit
Autenticación	Básica de Windows
Tipo de equilibrador de carga	Equilibrio de carga de hardware
Versión de software	SharePoint Server 2010 (versión preliminar)
Servicios que se ejecutan localmente	Administración central Correo electrónico entrante de Microsoft SharePoint Foundation Aplicación web de Microsoft SharePoint Foundation Servicio de temporizador de flujo de trabajo de Microsoft SharePoint Foundation

En la siguiente tabla se describe el hardware del servidor de bases de datos usado durante estas pruebas.

Especificaciones de hardware para los servidores de bases de datos

	Servidor de bases de datos
Procesadores	4 procesadores de cuatro núcleos a 3,19 GHz
RAM	16 GB
Sistema operativo	Windows Server 2008 de 64 bits
Almacenamiento	15 discos de 300 GB a 15.000 RPM
Número de adaptadores de red	2
Velocidad del adaptador de red	1 gigabit
Autenticación	NTLM
Versión de software	Microsoft SQL Server 2008

Glosario

En este documento encontrará algunos términos especializados. Estos son algunos términos clave y sus definiciones:

• RPS   Solicitudes por segundo. La cantidad de solicitudes recibidas por una granja o un servidor en un segundo. Esta es una medición común de carga del servidor y de la granja de servidores.

  Observe que las solicitudes difieren de las cargas de página; cada página contiene varios componentes, cada uno de los cuales crea una o varias solicitudes cuando se carga la página. Por lo tanto, una carga de página crea varias solicitudes. Normalmente, los eventos y las comprobaciones de autenticación que no tienen un uso intensivo de recursos no se cuentan en las mediciones de RPS.

• Zona verde   Es el estado en el que el servidor puede mantener el siguiente conjunto de criterios:

  • La latencia del servidor de al menos el 75% de las solicitudes es menor que 1 segundo.

  • Todos los servidores tienen un uso de CPU menor que el 50%.

  • La frecuencia de errores es menor que el 0,01%.

Implementaciones de administración de contenido web

Existen dos modelos mediante los cuales se crea contenido en los sitios de publicación de SharePoint que pueden influir en su elección de una topología de granja de servidores.

En el modelo de autor en contexto, se comparte una sola colección de sitios entre autores y visitantes. Los autores pueden crear y actualizar el contenido en cualquier momento, lo que genera distribuciones variables de operaciones de lectura y escritura a lo largo de un día determinado. Normalmente, esta granja de servidores experimenta gran cantidad de lecturas y un número moderado de escrituras.

En el siguiente diagrama se muestra cómo funciona la creación en contexto desde la perspectiva de una topología.

En el modelo de distribución de contenido, varias colecciones de sitios admiten la publicación y creación de contenido por separado y de forma exclusiva. El contenido se crea y actualiza en el entorno de creación y, a continuación, se implementa en el entorno de publicación de forma programada para que puedan leerlo los visitantes. El entorno de publicación principalmente atiende solicitudes de lectura, excepto cuando el contenido se implementa desde el entorno de creación. A diferencia del modelo de autor en contexto, la carga del servidor empleada por la distribución de contenido puede ajustarse a intervalos programados.

En el siguiente diagrama se muestra cómo funciona la distribución de contenido desde la perspectiva de una topología.

Estos modelos de creación de contenido se excluyen mutuamente.

Si bien los sitios de publicación en Internet y los sitios de publicación en la intranet pueden usar tanto el modelo de autor en contexto como el modelo de distribución de contenido, los sitios wiki empresariales funcionan mejor con el modelo de autor en contexto. Un sitio wiki empresarial experimenta un volumen mayor de operaciones de escritura en relación con las operaciones de lectura, ya que un mayor porcentaje de usuarios puede editar las páginas. Las páginas wiki empresariales difieren de las páginas de artículo de publicación y presentan características de rendimiento diferentes.

Optimizaciones necesarias

En esta sección se ofrece información para optimizar el entorno de administración de contenido web. Para optimizar el entorno se debe comprender cómo administrar el rendimiento, los cuellos de botella y el almacenamiento en caché.

En esta sección:

• El rendimiento es el valor métrico clave

• Cuellos de botella y su solución

• Ventajas del almacenamiento en caché

El rendimiento es el valor métrico clave

El rendimiento y el tiempo de respuesta son los valores métricos más importantes que deben optimizarse al realizar la planeación de la capacidad para una implementación de administración de contenido web de SharePoint Server 2010. El rendimiento es la cantidad de operaciones que puede llevar a cabo una granja de servidores por segundo y se mide en RPS.

Cuellos de botella y su solución

Un cuello de botella es aquel recurso del sistema que, cuando se agota, impide que la granja siga atendiendo otras solicitudes. En el siguiente diagrama se muestran los elementos de una granja y los recursos que pueden convertirse en cuellos de botella y que, por lo tanto, deben supervisarse.

Uso de CPU del servidor web

La CPU del servidor web debería ser el cuello de botella de una topología bien ajustada, ya que es el componente más fácil de escalar. El equilibrador de carga redirige las solicitudes entre los servidores web y se asegura de que ningún servidor se use en un grado considerablemente mayor que el resto.

Aunque otros usuarios pueden seguir visitando el sitio después de agotarse por completo el uso de la CPU del servidor web, el tiempo de respuesta del servidor que experimentan estos usuarios es mayor. Este comportamiento resulta útil para administrar puntas en el volumen de solicitudes. Sin embargo, una carga continua que sobrepase la capacidad de la granja de servidores finalmente ocasionará un trabajo pendiente de solicitudes que será suficientemente grande como para exceder el umbral de solicitudes en espera. En este momento, los servidores web limitarán las solicitudes y responderán con un error HTTP 503. En la siguiente ilustración, el tiempo de respuesta del servidor disminuye cuando se alcanza el umbral de solicitudes en espera debido a que solo se sirven los errores HTTP.

En este diagrama se muestran los siguientes cambios:

1. El tiempo de respuesta aumenta a medida que el uso de CPU del servidor web se acerca al 100%.

2. Una vez excedido el umbral de solicitudes en espera, las solicitudes adicionales se atienden con errores.

Otros cuellos de botella

Si la CPU del servidor web no es el cuello de botella, los siguientes elementos en los que deben buscarse cuellos de botella son la topología de granja de servidores, la configuración de la granja o el contenido de las páginas que se sirven. Entre algunos de los posibles cuellos de botella en estos elementos se incluyen los siguientes:

1. Red    En situaciones de alto rendimiento, es posible que la red se sature entre el servidor web y el servidor de bases de datos o entre el servidor web y los usuarios finales. Para evitar esta situación, se recomienda que los servidores web usen adaptadores de red de dos gigabits.

2. CPU del servidor de bases de datos    Si la CPU del servidor de bases de datos se convierte en el cuello de botella, la adición de servidores web a la granja de servidores no puede incrementar el rendimiento máximo que puede admitir la granja. Un cuello de botella con la CPU de la base de datos pero sin las CPU del servidor web puede reflejar dos situaciones:

   1. Una configuración de caché insuficiente o páginas muy lentas, especialmente aquellas que no se almacenan en la memoria caché de resultados. Esto se caracteriza por un alto uso de CPU del servidor de bases de datos, pero un rendimiento bajo o medio o un uso del servidor web bajo o medio.

   2. Es posible que el servidor de bases de datos haya alcanzado la capacidad del rendimiento requerido para la granja. Esto se caracteriza por un alto uso de CPU del servidor web y del servidor de bases de datos durante un rendimiento alto.

Ventajas del almacenamiento en caché

SharePoint Server 2010 usa tres tipos de almacenamiento en caché. Su objetivo común es mejorar la eficacia mediante la disminución de las llamadas a la base de datos para los datos que se solicitan con frecuencia. Las solicitudes posteriores de una página pueden atenderse desde la memoria caché del servidor web, lo que disminuye considerablemente el uso de recursos en los servidores web y de bases de datos.

Los tres tipos de almacenamiento en caché son los siguientes:

• Caché de resultados   Esta memoria caché almacena el contenido de la página solicitada en la memoria del servidor web. Para obtener más información acerca de la memoria caché de resultados, vea el tema sobre el almacenamiento en la memoria caché de resultados y los perfiles de memoria caché (https://go.microsoft.com/fwlink/?linkid=121543&clcid=0xC0A).

• Caché de objetos   Esta memoria caché almacena objetos de SharePoint, como metadatos web y de elemento de lista, en la memoria del servidor web. Para obtener más información acerca de la memoria caché de objetos, vea el tema sobre el almacenamiento en caché de objetos (https://go.microsoft.com/fwlink/?linkid=123948&clcid=0xC0A).

• Caché basada en disco de objetos binarios grandes (BLOB)   Esta memoria caché almacena archivos de vídeo, imagen, sonido y otros archivos binarios grandes en el disco. Para obtener más información acerca de la memoria caché BLOB, vea el tema sobre el almacenamiento en memoria caché basada en disco de objetos binarios grandes (https://go.microsoft.com/fwlink/?linkid=123947&clcid=0xC0A).

Cada una de estas memorias caché es importante para mantener un alto rendimiento. No obstante, el almacenamiento en la memoria caché de resultados es el que causa un mayor efecto y se describe en detalle a lo largo de este artículo.

Resultados de las pruebas y recomendaciones

En esta sección se describen las áreas específicas donde se realizaron pruebas y se proporcionan las recomendaciones obtenidas como resultado.

En esta sección:

• Efecto de la habilitación de la memoria caché de resultados

• Usuarios anónimos y usuarios autenticados

• Características de escalabilidad horizontal de las operaciones de lectura y escritura

• Advertencias sobre la memoria caché de resultados

• Efecto del volumen de lecturas en la CPU y en el tiempo de respuesta

• Efecto de las operaciones de escritura en el rendimiento

• Efecto de la distribución de contenido

• Efecto de la instantánea de base de datos durante la exportación de distribución de contenido

• Características del contenido

Efecto de la habilitación de la memoria caché de resultados

La memoria caché de resultados es una característica de gran valor que puede usarse para optimizar una solución de SharePoint Server 2010 para gran cantidad de operaciones de lectura.

En estas pruebas, para determinar el máximo de RPS, la cantidad de usuarios activos que realizan solicitudes en la granja de servidores se incrementó hasta que el uso de CPU del servidor de bases de datos o de los servidores web alcanzó el 100% y se convirtió en un cuello de botella. La prueba se realizó en topologías de granja de servidores de 1x1 (un servidor web y un servidor de bases de datos), 2x1, 4x1 y 8x1 para demostrar el efecto del incremento de la escalabilidad horizontal de los servidores web en diferentes proporciones de aciertos de la memoria caché de resultados.

Proporción de aciertos de la memoria caché de resultados

La proporción de aciertos de la memoria caché de resultados es una medición de los aciertos de la memoria caché de resultados con respecto a los errores de caché.

• Un acierto de caché se produce cuando la memoria caché recibe una solicitud de datos de objeto que ya están almacenados en la memoria caché.

• Un error de caché se produce cuando se recibe una solicitud de datos de objeto que no están almacenados en la memoria caché. Cuando se produce un error de caché, la memoria caché intentará almacenar los datos de objeto solicitados para que las solicitudes posteriores de dichos datos produzcan un acierto de caché.

Existen varias razones por las que una solicitud de página puede producir un error de caché.

• Páginas configuradas para no usar la memoria caché de resultados.

• Páginas personalizadas, por ejemplo, páginas que contienen datos específicos del usuario actual.

• Primera exploración por clave de variante de caché de resultados.

• Primera exploración después de que haya caducado o expirado el contenido almacenado en caché.

En el siguiente diagrama se muestra el efecto del almacenamiento en la memoria caché de resultados en el rendimiento máximo en granjas de servidores que contienen de uno a cuatro servidores web y un servidor de bases de datos.

En la siguiente tabla se enumeran los efectos de las proporciones de aciertos de la memoria caché de resultados en topologías de granja de servidores que contienen de uno a cuatro servidores web y un servidor de bases de datos.

Efectos de la proporción de aciertos de la memoria caché de resultados en topologías de granja de servidores diferentes

Proporción de aciertos de la memoria caché de resultados	Medida	1x1	2x1	4x1
100%	Máximo de RPS Uso de CPU de SQL Server	3.463 0%	7.331 0%	11.032 0%
95%	Máximo de RPS Uso de CPU de SQL Server	2.137 5,93%	3.945 12,00%	5.937 21,80%
90%	Máximo de RPS Uso de CPU de SQL Server	1.518 7,12%	2.864 14,40%	4.518 28,00%
50%	Máximo de RPS Uso de CPU de SQL Server	459 9,86%	913 19,50%	1.596 42,00%
0%	Máximo de RPS Uso de CPU de SQL Server	172 9,53%	339 19,00%	638 36,30%

Conclusiones y recomendaciones sobre el efecto de la habilitación de la memoria caché de resultados

Las proporciones de aciertos de la memoria caché de resultados más altas provocan aumentos considerables del máximo de RPS. Por lo tanto, se recomienda habilitar el almacenamiento en la memoria caché de resultados para optimizar la solución de publicación de SharePoint Server 2010. Puede configurar la memoria caché de resultados en la página Configuración de la memoria caché de resultados de la colección de sitios. Para obtener más información, vea el tema sobre la configuración de la memoria caché de resultados de la página para una colección de sitios (https://go.microsoft.com/fwlink/?linkid=205058&clcid=0xC0A) en el sitio web Office.Microsoft.com.

En las pruebas donde el almacenamiento en la memoria caché de resultados estaba habilitado, se excluyó la primera solicitud que almacenaba una página en caché; es decir, un cierto porcentaje de páginas ya está almacenado en caché. La primera vez que un usuario solicita una página que no está almacenada en caché, dicha página se agrega a la memoria. Si la memoria caché ha alcanzado la capacidad o se está acercando a ella, la memoria recorta aquellos datos que no se han solicitado recientemente.

La proporción de aciertos de la memoria caché del 0% simula el período de corta duración durante el cual la memoria caché de resultados habilitada se rellena después de haberse vaciado. Por ejemplo, esto se observa a diario en un entorno real cuando se recicla el grupo de aplicaciones. Es importante escalar adecuadamente el hardware horizontal o verticalmente para adaptarse a una situación donde hay una proporción de aciertos de la memoria caché del 0% en el período de corta duración entre el reciclaje del grupo de aplicaciones y la próxima solicitud y almacenamiento en caché de las páginas. La proporción de aciertos de la memoria caché del 0% también simula un entorno en el que el almacenamiento en la memoria caché de resultados no está habilitado.

Usuarios anónimos y usuarios autenticados

En la prueba anterior se supone que todas las solicitudes en el sitio se realizan por parte de lectores anónimos. Sin embargo, en su sitio, es posible que algunos de los usuarios estén autenticados. Entre los ejemplos de escenarios de lectura autenticada se incluyen un sitio de publicación en la intranet corporativa y contenido solo para miembros de un sitio de Internet.

Con los perfiles de caché de resultados, puede especificar el comportamiento de la memoria caché de resultados para usuarios autenticados, que difiere del comportamiento para usuarios anónimos.

Perfiles de caché

Los perfiles de caché agregan configuración que puede aplicarse a páginas, elementos de página, tipos de contenido y niveles de escala en la implementación de un sitio. Un perfil de caché define los siguientes tipos de comportamiento de caché:

• El período de tiempo que los elementos deben permanecer en la memoria caché.

• La directiva de recorte de seguridad.

• La expiración de la configuración, como la duración y los cambios.

• Las variantes del contenido almacenado en caché, por ejemplo en función de los permisos de usuario, los derechos de usuario y otras variables personalizadas.

Cualquier cambio a un perfil de caché afecta inmediatamente a todo el contenido aplicable del sitio. Puede establecer distintos perfiles de caché para usuarios anónimos y para usuarios autenticados.

Para los usuarios anónimos, se usó el perfil de caché de resultados Internet público (totalmente anónimo) y para los usuarios autenticados se usó el perfil de caché de resultados Extranet (sitio publicado).

En el siguiente gráfico se muestran los efectos del rendimiento autenticado en el uso de CPU del servidor de bases de datos.

El modelo de autenticación que se usó es la autenticación básica de Windows. Si bien no se recomienda usar la autenticación básica de Windows para sitios de Internet, se seleccionó este método de autenticación para demostrar una sobrecarga mínima impuesta por la autenticación. El tamaño de esta sobrecarga varía según el mecanismo de autenticación específico. Al probar su implementación, asegúrese de tener en cuenta el efecto del mecanismo de autenticación. Para obtener más información acerca de los mecanismos de autenticación admitidos por SharePoint Server 2010, vea Planeación de los métodos de autenticación (SharePoint Server 2010).

Conclusiones y recomendaciones sobre usuarios anónimos y usuarios autenticados

Los usuarios autenticados experimentan RPS más bajas y un menor potencial de escalabilidad horizontal, ya que el trabajo adicional de validar las credenciales ejerce una carga en el servidor de bases de datos. Como se demostró en los resultados de las pruebas, el máximo de RPS observado cuando se autentica a los usuarios es considerablemente menor que el de una granja de servidores de acceso anónimo.

Características de escalabilidad horizontal de las operaciones de lectura y escritura

Las pruebas se crearon para registrar las escrituras por hora. En este artículo, una escritura se define como la creación y protección de una nueva página de publicación o la edición y protección de una página de publicación existente.

En las pruebas siguientes, se agregaron lectores al sistema hasta que el uso de CPU del servidor web alcanzó aproximadamente el intervalo del 80-90% y, posteriormente, se realizaron operaciones de escritura en el entorno mediante un retraso artificial. El total de escrituras por hora en la prueba fue de aproximadamente 500. Se usó una proporción de aciertos de la memoria caché de resultados del 90% para todas las pruebas. Se llevó a cabo la misma prueba en granjas de servidores de 1x1, 2x1 y 4x1 y se observó el uso de CPU de SQL Server y del servidor web además del rendimiento de lectura general para cada configuración. Además, se probó una configuración de solo lectura anónima como línea base, así como una configuración con lectores autenticados mediante la autenticación básica de Windows.

Aunque la CPU del servidor web se usó completamente en un 100% durante las pruebas de escalabilidad horizontal de solo lectura, se mantuvo la CPU del servidor web entre el 80% y el 90% para las pruebas de escalabilidad horizontal con las escrituras. Esto se ha hecho para dejar espacio para uso de CPU adicional al llevar a cabo una operación de escritura.

En el siguiente gráfico se muestran las RPS de lectura generales observadas durante cada prueba. Las RPS de lectura se escalan linealmente a medida que se agregan servidores web adicionales, incluso con la actividad de escritura. No obstante, existe una pérdida de RPS cuando se incorporan escrituras.

El uso de CPU del servidor de bases de datos se incrementó a medida que aumentó la cantidad de servidores web. En el siguiente gráfico se muestra el patrón de crecimiento del uso de CPU de SQL Server en las diferentes configuraciones. Como se mencionó en la sección Usuarios anónimos y usuarios autenticados anteriormente en este artículo, la autenticación afecta al uso de CPU del servidor de bases de datos y esto se acentúa aún más a medida que se agrega actividad de escritura (que también afecta al uso de CPU del servidor de bases de datos).

La tendencia extrapolada en el uso de SQL Server demuestra que SQL Server se convertirá en el cuello de botella con seis servidores web que tienen solicitudes de lectura autenticadas. Sin embargo, en el caso de lectura anónima, puede servir el incremento de la escalabilidad horizontal a un mayor número de servidores web.

Es importante comprender que en una implementación típica existen factores adicionales que afectan a la carga del servidor de bases de datos, y es importante tener en cuenta estos factores al planear la capacidad. Para obtener más información acerca de cómo determinar una zona verde para el uso de CPU típico del servidor de bases de datos, vea Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010.

Conclusiones y recomendaciones sobre las características de escalabilidad horizontal de las operaciones de lectura y escritura

En los datos se muestra que el incremento de la escalabilidad horizontal del número de servidores web es una estrategia eficaz para incrementar el rendimiento si el servidor de bases de datos no se convierte en el cuello de botella. En promedio, la combinación de pruebas de escrituras autenticadas y lectura anónima empleó un aumento del 52% en el uso de CPU del servidor web en comparación con la combinación de pruebas de lectura anónima sin escrituras. Además, las lecturas autenticadas agregan una gran carga de SQL Server adicional, ya que cada carga implica comprobaciones de autenticación adicionales, lo que requiere una ida y vuelta a SQL Server.

En el siguiente gráfico se muestra el efecto del rendimiento en el uso de CPU del servidor de bases de datos.

Advertencias sobre la memoria caché de resultados

Si lo único que debe tenerse en cuenta en la planeación de la capacidad es maximizar las RPS, estas pruebas indicarían que la proporción de aciertos de la memoria caché óptima es del 100%. No obstante, es posible que no sea factible o deseable habilitar el almacenamiento en la memoria caché de resultados en algunas páginas, o en todas ellas, debido a requisitos de actualización de datos o a restricciones de memoria.

Actualización de datos

Es posible que los datos que se sirven desde la memoria caché de resultados no contengan actualizaciones recientes llevadas a cabo en el contenido original. En el origen de la distribución de contenido o (para autores autenticados) en un escenario de autor en producción, es posible que los autores deseen ver los cambios más recientes inmediatamente después de actualizar el contenido existente.

Generalmente, esto se facilita al establecer la propiedad Duración en el perfil de caché, la cual especifica cuánto tiempo una página almacenada en caché persistirá en la memoria caché de resultados antes de expirar. Cuando una página expira, se quita de la memoria caché y una consulta posterior producirá un error de caché que actualizará el contenido de la página.

También se puede establecer la propiedad de perfil de caché Buscar cambios para que el servidor compare la hora en la que se almacenó una página en caché con la hora en que el contenido se modificó por última vez en una colección de sitios. Una solicitud de una página cuyas marcas de tiempo no coinciden ocasionará una invalidación de caché en todas las páginas de la colección de sitios. Dado que la propiedad Buscar cambios afecta a todas las páginas de una colección de sitios, se recomienda habilitar esta opción únicamente si se trata de una solución de autor en contexto autenticada que no se actualiza frecuentemente y que es básicamente estática. La combinación de esta opción con una larga duración permite que todas las páginas se sirvan desde la memoria caché hasta que se realice una actualización en el sitio.

De manera predeterminada, la propiedad Buscar cambios no está habilitada. Esto significa que el servidor web sirve los datos desde la memoria caché de resultados en respuesta a solicitudes de una página que todavía no ha expirado, independientemente de si se modificó la página ASPX original subyacente.

En esta prueba, realizada en una granja de servidores de 1x1, todas las variables son las mismas que en las pruebas de la sección Características de escalabilidad horizontal de las operaciones de lectura y escritura, excepto la propiedad Buscar cambios. Cuando se activa la propiedad Buscar cambios, la memoria caché se vacía más seguido, lo que ocasiona una menor proporción de aciertos de la memoria caché de resultados.

En el siguiente gráfico se muestra el efecto de la propiedad Buscar cambios en el rendimiento.

Se recomienda evitar la propiedad de perfil de caché de resultados Buscar cambios, excepto en casos específicos. Un sitio que usa el modelo de autor en contexto y no experimenta cambios frecuentes en el contenido puede beneficiarse de este valor para los usuarios autenticados junto con una larga duración, pero lo más probable es que otros tipos de sitios observen una degradación en RPS.

En función de sus requisitos, es posible que desee que el contenido sujeto a limitación temporal se publique instantáneamente o más rápido que lo permitido por la configuración predeterminada. En este caso, debe disminuir la duración o deshabilitar el almacenamiento en la memoria caché de resultados.

Conclusiones y recomendaciones sobre las advertencias de la memoria caché de resultados

El almacenamiento en la memoria caché de resultados no resuelve todos los problemas relacionados con la administración de la capacidad. En algunas situaciones, el almacenamiento en la memoria caché de resultados no es adecuado, por lo que debe tener en cuenta dichas situaciones al habilitar la memoria caché de resultados y configurar los perfiles de caché de resultados.

Efecto del volumen de lecturas en la CPU y en el tiempo de respuesta

Esta prueba se llevó a cabo en una granja de servidores de 1x1 con acceso anónimo y el almacenamiento en la memoria caché de resultados habilitado.

En el siguiente gráfico se muestra el efecto del volumen de lecturas en la CPU y en el tiempo de respuesta.

Conclusiones y recomendaciones sobre el efecto del volumen de lecturas en la CPU y en el tiempo de respuesta

Como se describió en la sección Cuellos de botella y su solución, el tiempo de respuesta del servidor generalmente será coherente hasta que el servidor web reciba un volumen de solicitudes suficiente para usar completamente su CPU. Cuando la CPU del servidor web se usa por completo, el tiempo de respuesta aumenta considerablemente. No obstante, la granja de servidores aún podrá administrar un volumen de solicitudes adicional.

Efecto de las operaciones de escritura en el rendimiento

La proporción de la creación de operaciones de edición se distribuye equitativamente en el transcurso de las pruebas. Los valores de escrituras por hora se probaron hasta aproximadamente 500, ya que la creación o edición de más de 500 páginas por hora se encuentra fuera del intervalo en el que operarían la mayoría de las implementaciones de SharePoint. En la prueba no se incluyeron los procesos automatizados, como la distribución de contenido, la cual se describe en la sección Efecto de la distribución de contenido. Es posible que estas operaciones de creación y edición conlleven varias operaciones de SQL Server. Por lo tanto, es importante tener en cuenta que las escrituras que se miden en estas pruebas no se encuentran en el nivel de SQL Server, sino que representan lo que un usuario consideraría una operación de escritura. Todas las pruebas de RPS frente a escrituras por hora se llevaron a cabo en una granja de servidores de 1x1.

En primer lugar, se agregaron operaciones de lectura a la prueba hasta que el uso de CPU del servidor web se encontró entre el 60% y el 80% para dejar un búfer para las puntas de tráfico, y se mantuvo este nivel de uso promedio durante el transcurso de toda la prueba. A continuación, se incorporaron escrituras mediante un retraso artificial para controlar la cantidad de operaciones de escritura. No obstante, hubo puntas de uso de CPU incrementado de SQL Server y del servidor web mientras se llevaban a cabo las escrituras. Algunas de estas puntas en algunas proporciones de aciertos de la memoria caché excedieron el umbral de la operación común, como se muestra en el siguiente gráfico, aunque la media se mantuvo dentro del intervalo de la operación común

Como se muestra en el gráfico anterior, hay una reducción de poca importancia en el rendimiento a medida que se agregan escrituras al entorno. En el gráfico se muestra el cambio en el rendimiento entre un escenario de solo lectura y las operaciones de lectura durante aproximadamente 500 escrituras por hora. Se registraron dos puntos de datos para cada proporción de aciertos de la memoria caché de resultados. Por lo tanto, la relación entre los puntos de datos no es necesariamente lineal.

La reducción en porcentaje es más pronunciada en las proporciones de aciertos de la memoria caché más bajas, como se muestra en el siguiente gráfico. Las RPS de lectura generales dependen en gran parte de la proporción de aciertos de la memoria caché, independientemente de las escrituras.

En el siguiente gráfico se muestra que el uso de CPU del servidor de bases de datos no se incrementó perceptiblemente al agregar escrituras al sistema. Observe que la escala vertical es del 0% al 10% de la capacidad de CPU.

Se observó una carga de SQL Server adicional durante las operaciones de lectura, lo cual estaba previsto. No obstante, el mayor aumento fue de un 2,06% adicional, lo que es insignificante. El uso de CPU del servidor de bases de datos promedio se mantuvo por debajo del 10% en todas las pruebas. Esta prueba se realizó en una granja de servidores de 1x1. El uso de CPU del servidor de bases de datos aumentará a medida que la cantidad de servidores web se escale horizontalmente. Esto se describe en más detalle en Características de escalabilidad horizontal de las operaciones de lectura y escritura.

Durante las pruebas, también se midió el uso de CPU del servidor web. En el siguiente gráfico se muestra que el uso de CPU del servidor web promedio se mantuvo en un intervalo del 60-80% durante el transcurso de las pruebas, incluso a medida que las escrituras por hora se aproximaban a 500.

No obstante, el uso de CPU medido real genera puntas cuando se llevan a cabo las escrituras, como se muestra en el siguiente gráfico. En general, estas puntas de CPU no representan un problema. El objetivo de la zona verde es proporcionar margen adicional de CPU para absorber algunas puntas en la carga de CPU. Además, a medida que se agregan servidores web adicionales, el efecto de las puntas se distribuye en estos servidores para reducir el efecto en una sola CPU del servidor web. No obstante, debe saber que dichas puntas están previstas en un entorno real, ya que la actividad de escritura no se distribuye uniformemente, aunque generalmente se lleva a cabo en ráfagas.

Una proporción de aciertos de la memoria caché del 90% es muy baja para una implementación típica. La mayoría de las implementaciones de SharePoint Server 2010 con gran cantidad de operaciones de lectura tendrán una proporción de aciertos del 95% o superior en la memoria caché de resultados.

Conclusiones y recomendaciones sobre el efecto de las operaciones de escritura en el rendimiento

Los datos presentados indican que las operaciones de escritura no supondrán un gran efecto negativo en el rendimiento general del sistema para los lectores. Debe recordar que la actividad de escritura puede causar puntas en el uso de CPU y debe planear la configuración típica de modo que prevea estas puntas. Una estrategia para nivelar estas puntas es incrementar la escalabilidad horizontal a varios servidores web. Esto tiene dos ventajas:

• Dispersa la carga de escritura en varios servidores web, lo que suaviza las puntas totales.

• Proporciona un aumento en las RPS de lectura, especialmente en proporciones de aciertos de la memoria caché de resultados altas.

Efecto de la distribución de contenido

Una alternativa al modelo de autor en contexto, que usa un entorno único para la edición y la lectura, consiste en dividir el entorno único en dos entornos independientes (un entorno de creación y uno de producción) y en usar la distribución de contenido para copiar contenido del entorno de creación al entorno de producción.

En esta configuración, en el entorno de producción puede haber poca actividad de escritura o ninguna actividad de escritura en absoluto, excepto cuando la distribución de contenido importa contenido. En estas pruebas, se agregaron lecturas hasta que el uso de CPU del servidor web se encontró en el intervalo del 70-80%. Posteriormente, el trabajo de distribución de contenido exportó 10 sitios con 500 páginas cada uno desde la colección de sitios de creación como un paquete e importó dicho paquete a la colección de sitios de publicación. El tamaño del paquete implementado es mayor que lo observado normalmente en entornos reales con el fin de extender bastante la duración del trabajo de distribución de contenido para ver resultados de las pruebas. Para obtener información adicional acerca de las características del contenido implementado, vea la sección Conjunto de datos.

Una vez finalizada la exportación, se importó el contenido en una colección de sitios independiente y se midió el servidor de aplicaciones y la carga de SQL Server, además del rendimiento, mientras la importación se encontraba en curso. La prueba de importación se realizó en varias proporciones de aciertos de la memoria caché de resultados diferentes.

La observación clave es que la importación solo tiene un efecto menor en las RPS de lectura generales, como se muestra en el siguiente gráfico. También se observó que la importación no tuvo un efecto importante en el uso de CPU del servidor web, como se muestra en las siguientes tablas, independientemente de la proporción de aciertos de la memoria caché. No obstante, el efecto fue más evidente en la CPU de SQL Server, como se muestra en el siguiente gráfico. Esto estaba previsto, ya que el servidor de bases de datos experimenta una carga adicional cuando se importa el contenido en él. Sin embargo, la CPU de SQL Server se mantuvo por debajo del uso del 12% en todas las proporciones de aciertos de la memoria caché probadas, incluso durante la importación.

En las siguientes tablas se muestra el efecto de la importación de distribución de contenido en el uso de CPU del servidor de bases de datos y del servidor web.

Efecto de la importación de distribución de contenido en el uso de CPU del servidor web

Acierto de caché	100%	99%	98%	95%	90%	50%	0%
Línea base	72,32%	73,26%	71,28%	73,53%	71,79%	68,05%	63,97%
Con la importación	70,93%	74,45%	69,56%	74,12%	70,95%	67,93%	63,94%

Efecto de la importación de la distribución de contenido en el uso de CPU del servidor de bases de datos

Acierto de caché	100%	99%	98%	95%	90%	50%	0%
Línea base	1,19%	1,64%	2,01%	3,00%	3,73%	5,40%	6,82%
Con la importación	6,03%	6,82%	6,97%	7,96%	8,52%	10,29%	10,56%

Conclusiones y recomendaciones sobre el efecto de la distribución de contenido

En los resultados de las pruebas se muestra que llevar a cabo operaciones de distribución de contenido durante las operaciones del sitio comunes no implica un problema importante en el rendimiento. En estos resultados se muestra que no es estrictamente necesario implementar contenido durante períodos de tráfico bajo para minimizar el efecto de la operación en el rendimiento general y que los tiempos de implementación pueden controlarse principalmente en función de las necesidades de negocio en lugar de los requisitos de rendimiento.

Efecto de la instantánea de base de datos durante la exportación de distribución de contenido

En SharePoint Server 2010, la distribución de contenido puede configurarse para crear una instantánea de la base de datos de contenido de origen antes de exportar su contenido. Esto protege eficazmente el proceso de exportación de cualquier actividad de creación que pueda llevarse a cabo durante la exportación. No obstante, las instantáneas pueden afectar al rendimiento de escritura del servidor de bases de datos, ya que actúan como multiplicadores de las escrituras. Por ejemplo, si tiene dos instantáneas de una base de datos de origen y, a continuación, escribe en dicha base de datos, el servidor de bases de datos copia los datos existentes en cada instantánea y, posteriormente, escribe los datos nuevos en la base de datos de origen. Esto significa que una sola escritura en la base de datos de origen provoca tres escrituras reales: una en la base de datos de origen y otra en cada instantánea de base de datos.

Para determinar el efecto de una instantánea en el entorno de creación, se midieron las RPS de escritura, el tiempo de respuesta y el uso de CPU de los servidores web, del servidor de bases de datos y del servidor de aplicaciones durante una operación de exportación mientras también se llevaba a cabo una actividad de escritura. En las siguientes tablas se muestran los resultados.

Efecto de las instantáneas de base de datos durante la distribución de contenido

Valor métrico	4 WPH - Sin instantáneas	4 WPH - Con instantáneas
RPS de escritura	0,2	0,16
Tiempo de respuesta	0,13	0,15
% de CPU del servidor web	0,42%	0,27%
% de CPU del servidor de aplicaciones	8,67%	8,98%
% de CPU del servidor de bases de datos	3,34%	2,41%

Efecto de las instantáneas de base de datos durante la distribución de contenido

Valor métrico	8 WPH - Sin instantáneas	8 WPH - Con instantáneas
RPS de escritura	0,44	0,44
Tiempo de respuesta	0,13	0,13
% de CPU del servidor web	0,61%	0,73%
% de CPU del servidor de aplicaciones	14,6%	12%
% de CPU del servidor de bases de datos	7,04%	7,86%

Conclusiones y recomendaciones sobre el efecto de la instantánea de base de datos durante la exportación de distribución de contenido

En los resultados de las pruebas se muestra que no hubo un efecto importante en ningún punto de datos medido con las instantáneas de base de datos. Todas las varianzas registradas se encontraron dentro del margen de error. Esto confirma que las instantáneas de base de datos pueden usarse sin consideraciones de rendimiento importantes.

Características del contenido

Las pruebas se realizaron en un solo conjunto de datos creado para responder a un conjunto específico de preguntas. Su conjunto de datos diferirá y cambiará a lo largo del tiempo. En esta sección se investiga cómo las características del contenido, como el número de páginas de la biblioteca de páginas y las características incluidas en las páginas, pueden ayudar a tomar decisiones bien fundadas sobre la administración de la capacidad.

Número de páginas

Se probó el máximo de RPS en varios tamaños de bibliotecas de páginas. Esta prueba se llevó a cabo en una topología de 4x1 con el almacenamiento en la memoria caché de resultados deshabilitado y con acceso anónimo. Todas las páginas eran de 42 KB sin comprimir y 12 KB comprimidas. En la siguiente tabla se muestran los resultados de las pruebas.

Efecto del recuento de páginas de la biblioteca en las RPS

Número de páginas	3	1.000	20.000
Máximo de RPS	860	801	790

El aumento del número de páginas a 20.000 no supuso un efecto importante en el máximo de RPS.

Campos de búsqueda multivalor

Un campo de búsqueda multivalor es una columna de una lista que hace referencia a uno o varios elementos de otra lista, como columnas que usan metadatos administrados empresariales. Estos campos generalmente se usan como palabras clave de una página y no necesariamente se representan. En algunos casos, para sitios wiki empresariales de ejemplo, tiene sentido representar estos valores de campo en el contenido de las páginas. Por ejemplo, las páginas pueden archivarse en categorías cuando se crean (por ejemplo, Noticias internacionales, Interés humano y Deportes en un sitio de noticias) y la página maestra incluye un marcador de posición que mostrará al usuario en qué categoría se etiquetó la página.

Los campos de búsqueda multivalor hacen que se capturen más datos cada vez que se solicita una página. Por lo tanto, si hay muchos campos de búsqueda multivalor en una página, el rendimiento puede verse afectado.

En el siguiente gráfico se muestra el efecto de los campos de búsqueda multivalor en el rendimiento.

En el siguiente gráfico se muestra el efecto de los campos de búsqueda multivalor en el uso de recursos de la granja de servidores.

La degradación en el máximo de RPS tiene lugar a medida que aumenta la cantidad de campos de búsqueda multivalor debido al efecto en la red entre el servidor web y el servidor de bases de datos.

Efecto de los informes de uso

Los informes de uso son un servicio que ayuda a los administradores a supervisar las estadísticas sobre el uso de los sitios. Para obtener más información acerca de los informes de uso, vea Configuración de recolección de datos de uso y estado (SharePoint Server 2010).

Se probó el efecto de los trabajos del temporizador de informes de uso en el máximo de RPS en una granja de servidores de 1x1. En la siguiente tabla se describen los resultados.

Efecto del registro de uso en el rendimiento (en RPS)

	Base de datos de uso habilitada	Base de datos de uso deshabilitada	Diferencia
Caché de resultados habilitada	3.459	3.463	4
Caché de resultados deshabilitada	629	638	9

En los resultados se muestra que la habilitación del registro de uso no afecta de manera significativa a las RPS en un escenario de solo lectura.

Acerca de los autores

Joshua Stickler es jefe de programas de SharePoint Server 2010 en Microsoft.

Tyler Butler es jefe de programas de SharePoint Server 2010 en Microsoft.

Zhi Liu es ingeniero de desarrollo de software en pruebas para SharePoint Server 2010 en Microsoft.

Cheuk Dong es ingeniero de desarrollo de software en pruebas para SharePoint Server 2010 en Microsoft.

Philippe Flamm es ingeniero de desarrollo de software en pruebas para SharePoint Server 2010 en Microsoft.