Estimar la capacidad y el rendimiento de la administración de contenido web (SharePoint Server 2013)
SE APLICA A:
2013 
2016 2019 Subscription Edition SharePoint en Microsoft 365
Con frecuencia, las empresas usan SharePoint Server 2013 para publicar contenido al que los usuarios anónimos pueden acceder en un sitio de Internet y los usuarios autenticados, en un sitio de la intranet. Este artículo contiene datos de capacidad y rendimiento que ayudan a planear el número de equipos que usar y los tipos de equipos necesarios para publicar contenido y administrar contenido web en SharePoint Server 2013.
La publicación en SharePoint engloba diversos tipos de sitios de publicación y los métodos correspondientes disponibles para cada sitio. La finalidad de las características de publicación de SharePoint Server 2013 reside en ayudar a crear sitios de Internet, intranet y extranet de marca. Para obtener más información sobre la publicación de SharePoint Server 2013, vea Información general sobre la publicación en sitios de Internet, intranet y extranet en SharePoint Server.
Introducción
En este artículo se abordan los siguientes escenarios:
Sitio de presencia en Internet
Proporciona información a clientes, socios, inversores y posibles empleados. En este tipo de sitio, los usuarios anónimos de Internet pueden encontrar información sobre una corporación. Estos sitios suelen ir con marca y en ellos las compañías tienen un férreo control del contenido.
Sitio de negocio de Internet
Promociona los productos y servicios que una compañía ofrece a los clientes. Estos sitios pueden mostrar un catálogo de productos de la compañía.
Sitio de intranet
Una compañía publica este sitio internamente en la organización. Estos sitios comparten información para los usuarios autenticados y las compañías bien lo administran férreamente para restringir el acceso, bien lo mantienen abierto para todos los usuarios internos.
Sitio de extranet
Dan acceso a contenido dirigido a clientes, socios y empleados remotos. Estos sitios pueden proporcionar acceso a bases de conocimientos que utilicen contenido creado etiquetado con metadatos para clasificar los artículos. Los usuarios pueden buscar o explorar información específica, como artículos de solución de problemas o soporte técnico.
La publicación de colecciones entre sitios y el elemento web de búsqueda de contenido posibilitan que se reutilice el contenido en varias colecciones de sitios en estos escenarios. Estas características y funcionalidad afectan al modo que en se planea la capacidad. Para más información, consulte Información general sobre la publicación entre sitios en SharePoint Server.
Nota:
En este artículo denominaremos la publicación de colecciones entre sitios como publicación entre sitios.
La navegación administrada en SharePoint Server 2013 consiste en una navegación basada en taxonomía de un sitio de publicación. Para obtener más información, vea Información general sobre la navegación administrada en SharePoint Server.
Los datos de capacidad y rendimiento de este artículo contienen dos partes. La primera parte es el nuevo método de publicación entre sitios y la navegación administrada. La segunda parte usa el modelo author-in-place.
Nota:
Los escenarios descritos en este artículo son factibles en sitios tanto de publicación entre sitios como de creación en contexto. Las características de publicación entre sitios y navegación administrada no dependen la una de la otra y se pueden usar de manera independiente.
En los modelos que se usan en este artículo se explican las dos siguientes métricas fundamentales:
Rendimiento
Número de vistas de página por segundo que el sitio puede mantener
Tiempo de respuesta del servidor
Tiempo que el servidor necesita para procesar una solicitud, lo que afecta al tiempo que un usuario tarda en ver la página. Los tiempos de respuesta del servidor que indicamos en este documento son valores de percentil 95 y 50. Estos valores significan que el 95 por ciento y el 50 por ciento (respectivamente) de las solicitudes son más rápidas que el valor que se suministra. Estos valores se miden a través de la "duración" registrada en la base de datos de uso de SharePoint relativa a una solicitud determinada.
Actualización del contenido
El tiempo necesario para que un elemento actualizado se refleje en los resultados de búsqueda es una buena métrica que tener en cuenta al trabajar en escenarios de publicación entre sitios.
En los escenarios de este artículo se usan los dos estados siguientes:
Zona verde
El uso de los servidores está por debajo del 60 por ciento. Se trata del objetivo que conviene alcanzar la mayor parte del tiempo que los servidores estén en funcionamiento.
Zona roja
Los servidores están cerca de su uso completo. Esto puede considerarse un estado en el que el sitio de SharePoint está bajo una carga mayor de lo habitual. En la zona roja, los valores de tiempo de respuesta del servidor comienzan a subir a medida que el servidor trata de cubrir la demanda de las solicitudes entrantes.
Información sobre requisitos previos
Antes de leer este artículo, asegúrese de que conoce los conceptos más importantes relativos a la administración de la capacidad de SharePoint Server 2013. Los siguientes artículos sirven para saber cuál es el método recomendado de administración de la capacidad y proporcionan contexto sobre cómo usar la información de este artículo de forma eficaz.
Tenga en cuenta que existen algunas otras características que influyen en los escenarios de publicación y que no se contemplan en este artículo. Estos escenarios incluyen los canales de dispositivo, la optimización de SEO, las plantillas de visualización y las reglas de consulta. De igual modo, la funcionalidad y configuración de un sitio de publicación entre sitios no se explican en profundidad en este artículo. Para obtener más información, vea Planear la publicación entre sitios en SharePoint Server y Configurar soluciones de administración de contenido web en SharePoint Server.
Para obtener más información sobre la capacidad y el rendimiento para ayudar a comprender los datos de este artículo, vea Planeamiento del rendimiento en SharePoint Server 2013.
Publicación entre sitios mediante navegación administrada
En esta sección encontrará nuestros datos de prueba de dos áreas: la publicación entre sitios con usuarios anónimos y la publicación de creación en contexto.
Publicación entre sitios con usuarios anónimos
Los resultados de prueba de esta sección se basan en un modelo de sitio de publicación entre sitios básico que ayuda a proporcionar directrices de planeación de la capacidad. Cuando planee una implementación de SharePoint para que los usuarios anónimos puedan acceder a un sitio web, use estas directrices y adapte sus especificaciones de implementación según corresponda.
En el caso de prueba de nuestras pruebas se usa la característica de publicación entre sitios. Este escenario ofrece contenido repartido en varias colecciones de sitios marcadas como catálogos que la aplicación de servicio de búsqueda de SharePoint rastrea. Los elementos web que emplean tecnología de búsqueda (como el elemento web de búsqueda de contenido y el elemento web de reutilización de elementos de catálogo) muestran contenido en las páginas de otro sitio. Para más información, consulte Información general sobre la publicación entre sitios en SharePoint Server.
Usamos las siguientes características en el modelo del sitio que creamos para probar la publicación entre sitios:
Sitio web de publicación con aproximadamente 5 millones de páginas o elementos.
Los elementos están asociados con alrededor de 1.000 categorías.
El contenido está en otras colecciones de sitios en uno o varios catálogos.
El sitio web usa navegación administrada vinculada a las categorías con las que están asociados los elementos.
Para la topología de implementación de línea base que se describe más adelante en esta lista, el sitio web recibe hasta 80 vistas de página por segundo de media. Los períodos máximos alcanzan hasta 100 vistas de página por segundo. Para escalar verticalmente este número de rendimiento, agregue procesos a la topología. Para reducir verticalmente este número de rendimiento, quite los equipos de la topología.
El rastreador de búsqueda se ejecuta con rastreos continuos durante un intervalo de 1 minuto, con cinco actualizaciones por segundo del catálogo.
El sitio web presenta los siguientes patrones de página y tráfico:
Página de inicio con tres de elementos web de búsqueda de contenido y un elemento web de panel de refinamiento (recibe un 15 por ciento del tráfico).
Páginas de categorías con tres elementos web de búsqueda de contenido, un elemento web de panel de refinamiento de taxonomía y un elemento web de panel de refinamiento (recibe un 45 por ciento del tráfico).
Páginas de elementos de catálogo con un elemento web de reutilización de elementos de catálogo y dos elementos web de búsqueda de contenido (recibe un 40 por ciento del tráfico).
Cada elemento web de búsqueda de contenido y de reutilización de elementos de catálogo emite una consulta sincrónica.
Las páginas de elementos de catálogo no usan la caché de resultados de búsqueda anónima porque reciben una cantidad de tráfico pequeña.
La granja tiene la caché BLOB (objetos binarios grandes) activada en los equipos que funcionan como servidores front-end web.
En el siguiente diagrama se refleja la topología de servidores que se usa para probar este escenario:
Figura 1: Topología de servidores del entorno de pruebas
Un equipo que hospeda SQL Server con todas las bases de datos que SharePoint usa
Un equipo que hospeda las aplicaciones de servicio de SharePoint, el servicio de caché distribuida, el procesamiento de análisis de búsqueda y los roles de administración de búsqueda
Un equipo que hospeda el rastreador de búsqueda y los roles de procesamiento de contenido
Tres equipos que hospedan nodos de índice de contenido con procesamiento de consultas y que hacen de servidores web front-end
Nota:
Los equipos de esta prueba son equipos físicos donde se ejecuta Windows Server 2008 R2. Consulte la planeación de capacidad de la búsqueda y Planeación de capacidad para SharePoint Server 2013 para ver recomendaciones sobre cómo usar equipos virtuales y Windows Server 2012.
Importante
La configuración de nuestra topología de entorno de pruebas se ha optimizado para escenarios de publicación basados en la búsqueda. Esta configuración es distinta de los tipos de colaboración de las implementaciones de SharePoint. Por ejemplo, nuestra configuración usa los servidores web front-end como servidores de índice de búsqueda para lograr el mejor rendimiento posible. > En nuestra topología de laboratorio de pruebas aprendimos que el equipo que hospeda el servidor de aplicaciones estaba infrautilizado. Como resultado, colocamos el servicio de caché distribuida en este servidor de aplicaciones en lugar de en un servidor dedicado. Puede decidir hospedar el servicio de caché distribuida en un servidor dedicado del entorno. Para obtener el mejor rendimiento, no se recomienda hospedar el servicio de caché distribuida en un servidor front-end web que tenga el rol de servidor de índice de búsqueda.
Informes del entorno de pruebas
Usamos la topología de la figura 1 en nuestro entorno de pruebas con equipos físicos y una prueba de carga de Visual Studio Team System (VSTS). Para obtener más información, vea Visual Studio Team System. En las siguientes tablas se recogen las especificaciones técnicas de los equipos de prueba.
Nota:
En nuestras pruebas de VSTS no hemos usado el almacenamiento en caché del explorador ni solicitudes dependientes (como imágenes o archivos JavaScript). Según cómo personalice su sitio de publicación, la cantidad de solicitudes dependientes que tiene lugar puede variar enormemente. > Las páginas que usamos en nuestras pruebas realizaron casi 50 tipos de solicitud de tiempo de carga de página 1 (PLT1) (caché vacía del explorador) y alrededor de 3 solicitudes para tipos de solicitud PLT2 (solicitudes posteriores con resultados de la caché del explorador). Por lo general, la caché BLOB de SharePoint se encarga de las solicitudes para estos elementos y no alterará significativamente nuestros números de rendimiento.
| Componentes de servidor | Servidores que ejecutan SharePoint Server |
|---|---|
| Procesadores | CPUs Intel Xeon a 2,27 GHz (2 procesadores, 8 núcleos en total, 16 subprocesos en total) |
| Memoria RAM | 24 GB |
| Sistema operativo | Windows Server 2008 R2 Enterprise SP1, 64 bits |
| Tamaño de la unidad de SharePoint | 200 GB de disco interno |
| Almacenamiento destinado al índice de búsqueda | 78 GB en una matriz de discos externa (2 SCSI Dell PERC H700) |
| Número de adaptadores de red | 2 |
| Velocidad del adaptador de red | 1 gigabit |
| Autenticación | Ninguno: anónimo |
| Versión de software | SharePoint Server 2013 |
| Componentes de servidor | Servidores de base de datos |
|---|---|
| Procesadores | CPUs Intel Xeon L5520 a 2,27 GHz (2 procesadores, 8 núcleos en total, 16 subprocesos en total) |
| Memoria RAM | 24 GB |
| Sistema operativo | Windows Server 2008 R2 Enterprise SP1, 64 bits |
| Matriz de discos | 2 SCSI Dell H700 |
| 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 R2 SP1 |
Los resultados de una ejecución de 10 minutos son los siguientes:
| Características de la prueba | Zona verde | Zona roja |
|---|---|---|
| Número de usuarios de VSTS (simulación de usuarios simultáneos): | 60 | 100 |
| Percentil 50 del tiempo de respuesta del servidor*: | 219 ms | 302 ms |
| Percentil 95 del tiempo de respuesta del servidor*: | 412 ms | 635 ms |
| Vistas de página por segundo: | 78 | 98 |
Este es un escenario de publicación entre sitios que muestra contenido del índice de búsqueda. Posiblemente sea interesante estudiar el número de consultas que atienden los servidores donde se hospedan las consultas de búsqueda y el número de consultas que atiende la memoria caché de resultados anónimos. En este modelo, la memoria caché de resultados anónimos se encarga de alrededor del 60 por ciento de las consultas. Más adelante en este artículo nos centraremos en la memoria caché de resultados anónimos.
| Características de la prueba | Zona verde | Zona roja |
|---|---|---|
| Número total de consultas por segundo: | 235 | 294 |
| Consultas procesadas por la memoria caché de resultados anónimos: | 145 | 182 |
| Consultas procesadas por la búsqueda: | 90 | 112 |
Los valores de uso medio de CPU y uso máximo de memoria de estos equipos mientras se ejecutaban las pruebas fueron los siguientes:
| Características de la prueba | Zona verde | Zona roja |
|---|---|---|
| Uso medio de CPU (nodos de índice de búsqueda por servidor front-end web) | 59% | 80% |
| Uso medio de CPU (servidor de aplicaciones con caché distribuida) | 8% | 9% |
| Uso medio de CPU (nodos de procesamiento de contenido de la búsqueda) | 5% | 5% |
| Uso medio de CPU (SQL Server) | No se ha medido | No se ha medido |
| Uso máximo de memoria (nodos de índice de búsqueda por servidor front-end web) | 7,5 GB | 7,5 GB |
| Uso máximo de memoria (servidor de aplicaciones con caché distribuida) | 10,1 GB | 10 GB |
| Uso máximo de memoria (nodos de procesamiento de contenido de la búsqueda) | 6,5 GB | 6,5 GB |
Observe que el uso de memoria puede diferir de alguna forma porque se ejecutan varios trabajos de temporizador en el servidor durante un uso normal. Vimos que los nodos de servidor front-end web /índice usaban hasta 12 GB de memoria tras una prueba ejecutada durante dos semanas con una carga continua.
Cómo muestran contenido los elementos web de búsqueda en las páginas de publicación entre sitios
Si una página de publicación contiene un elemento web de búsqueda, como el elemento web búsqueda de contenido, el explorador comienza a procesar la página antes de que se complete la consulta de búsqueda. Esto mejora la latencia percibida de la página. Una vez finalizada la consulta de búsqueda, los resultados completos de la consulta se envían al explorador y se cierra la conexión al explorador. Es posible que los usuarios piensen que los resultados de la búsqueda se cargan de forma asincrónica. Sin embargo, las consultas se siguen emitiendo desde el servidor mientras se solicita la página.
Tenga en cuenta que existe un modo asincrónico aparte para el elemento web de búsqueda de contenido en el que las consultas se emiten desde el explorador una vez que una página se ha cargado.
Efecto de los cambios de carga en el sitio de publicación entre sitios
Modificamos el número de usuarios de VSTS (similar al número de usuarios simultáneos que acceden al sitio) que se usaron en la prueba de carga. En el siguiente gráfico se aprecia que el tiempo de respuesta del servidor aumentaba cuando la carga lo hacía, y que se produce un ligero aumento incremental en el número de páginas procesadas por segundo. Se recomienda mantener el tiempo de respuesta del servidor por debajo de los 750 ms, ya que de este modo los usuarios podrán disfrutar de una experiencia de respuesta adecuada con la implementación de SharePoint.
Figura 2: Gráfico que muestra el rendimiento y los tiempos de respuesta del servidor con cargas diferentes
Escalado horizontal del sitio de publicación entre sitios
Si cree que la implementación de SharePoint va a recibir más o menos tráfico que en el caso de línea de base descrito anteriormente, posiblemente le interese cambiar el número de equipos que funcionan con el rol de servidor front-end web y de índice en la granja para, así, dar cabida al tráfico. En el siguiente gráfico se muestran los resultados de escalar horizontalmente el mismo sitio de publicación entre sitios con patrones de carga distintos y un número variable de equipos usados como servidores front-end web con nodos de índice, empezando por un único equipo en el rol de servidor front-end web con nodos de índice y llegando a seis equipos:
Figura 3: Escala horizontal de la implementación
En cada una de las configuraciones, la carga se ajusta para tener tiempos de respuesta del servidor con unos valores similares en comparación con la línea de base de la sección anterior.
Observe que, a medida que el número de equipos aumenta, la complejidad de la topología empieza a superar las ventajas. Cada equipo de más tiene un rendimiento inferior en comparación con los equipos que ya estaban en el entorno. Estos números se proporcionan para mostrar el patrón para escalar horizontalmente. El rendimiento real cambiará en función de cómo se compile la implementación de SharePoint.
Directrices para planear el sitio
En la mayor parte de nuestras pruebas de rendimiento se usó la implementación que se ha descrito en las secciones anteriores. Las directrices recogidas en la siguiente lista están pensadas para ayudarle a tomar las decisiones adecuadas de planeación de la capacidad cuando sus implementaciones sean distintas de las usadas en nuestro entorno de pruebas.
Por lo general, más elementos del índice de búsqueda significan una mayor latencia. Cada partición de índice puede contener hasta 10 millones de elementos. Los sitios web típicos rara vez tienen más de 10 millones de elementos para mostrar. Por lo tanto, solo necesitan una partición como en la topología que describimos anteriormente. Puede usar más particiones de índice para hospedar más de 10 millones de elementos o para tener más particiones de índice, más pequeñas y más rápidas. Si tiene previsto usar varias particiones de índice, consulte Búsqueda de escalado de sitios de Internet en SharePoint Server para ajustar el tamaño correcto de la topología de búsqueda.
Cada control o elemento web que se agrega a una página (o a un diseño de página) supondrá una sobrecarga en el tiempo de respuesta del servidor de la página.
Evite usar más de cinco elementos web sincrónicos de Búsqueda de contenido o Catalog-Item Reutilizar elementos web en una página. Al procesar una solicitud para una página, SharePoint Server 2013 ejecuta hasta cinco consultas en paralelo y devuelve los resultados. Si hay más de cinco consultas en una página, SharePoint Server 2013 ejecuta las cinco primeras consultas antes de empezar a ejecutar el siguiente conjunto de cinco consultas. Si las páginas requieren más de cinco elementos web de búsqueda de contenido o Catalog-Item reutilizar elementos web, puede ejecutar los elementos web de búsqueda de contenido adicionales en modo asincrónico o usar reglas de consulta y bloques de resultados.
Los elementos web de búsqueda de contenido y de reutilización de elementos de catálogo tienen un modo asincrónico. La consulta que se asocia al elemento web en cuestión se ejecuta después de que el explorador cargue la página. Emplee este modo en las consultas lentas para que el resto de la página se muestre más rápidamente a los usuarios. Si no, le recomendamos usar consultas sincrónicas para conseguir los mejores tiempos de carga de página.
Un elemento web de panel de refinamiento que tiene muchos refinadores aumenta el tiempo que una consulta tarda en procesarse. Puede cambiar el número de refinadores que se muestran en relación con una propiedad administrada. Para obtener más información, vea Configurar refinadores y navegación por facetas en SharePoint Server.
Si usa el elemento web de panel de refinamiento de taxonomía cuando existe una jerarquía muy profunda de nodos de navegación, aumentará el tiempo que una consulta tarda en procesarse. No recomendamos usar este elemento web en una página con más de 200 nodos de navegación. Un número de nodos de navegación alto puede ralentizar los tiempos de respuesta del servidor y disminuir el rendimiento.
En caso de que tenga que diseñar una implementación de SharePoint de alta disponibilidad, deberá agregar lo siguiente:
Un equipo extra que se ejecute con las aplicaciones de servicio en los roles de caché distribuida en caso de que el equipo existente no esté disponible
Equipos extra para mantener la carga si hay uno o más equipos de servidor front-end web con nodos de índice que no están disponibles
Un equipo extra con los roles de procesamiento de contenido para garantizar que las actualizaciones se sigan reflejando en el sitio cuando el equipo con el rol de procesamiento de contenido no esté disponible
Una topología de SQL Server que siga procesando las consultas de base de datos cuando uno de los servidores de base de datos no esté disponible
Velocidad de rastreo de búsqueda y actualización de contenido
En nuestro entorno de pruebas, también realizamos pruebas relativas al proceso que actualiza el contenido del catálogo que se iba a publicar. Así pudimos saber la cantidad de tiempo que un elemento actualizado tardaba en aparecer en el sitio de publicación. En nuestros experimentos, llevamos a cabo cinco actualizaciones por segundo en el catálogo y configuramos los rastreos continuos en el catálogo en intervalos de un minuto. Vimos que el tiempo medio que los cambios tardaban en reflejarse en el sitio de publicación fue de unos dos minutos. El tiempo mínimo estuvo por debajo del minuto, mientras que el máximo fue de tres minutos. No apreciamos un cambio notable en estas cifras cuando aumentamos el número de equipos que se ejecutaban con el rol de procesamiento de contenido.
Sin embargo, para el rastreo completo del catálogo, cuando aumentábamos el número de equipos que se ejecutaban con el rol de procesamiento de contenido, también lo hacía el número de elementos procesado por segundo. En el siguiente gráfico se muestra la relación entre elementos procesados por segundo y el número de equipos en la granja con el rol de procesamiento de contenido. Tenga presente que estos datos de prueba se han obtenido de una implementación de SharePoint distinta de la utilizada en las pruebas de línea de base. Estas averiguaciones se deben aplicar a las implementaciones de SharePoint, ya que la incorporación de más nodos de procesamiento de contenido supone una mejora de los tiempos de rastreo completo.
Figura 4: Efecto de los equipos de procesamiento de datos en un rastreo completo
En consecuencia, si necesita rastreos completos más rápidos en los catálogos, puede aumentar el número de equipos que usan el rol de procesamiento de contenido en su implementación.
Carga en la aplicación de servicio de metadatos administrados
Nuestras pruebas muestran que los escenarios de publicación que implican sitios que usan la navegación administrada no tienen requisitos significativos de memoria o CPU en la aplicación de servicio de metadatos administrados. Para una implementación como la que hemos descrito anteriormente, la aplicación de servicio de metadatos administrados se puede ejecutar en un equipo que ejecuta otras aplicaciones de servicio de SharePoint. La característica Navegación administrada realiza una conexión a la aplicación de servicio cuando recibe la primera solicitud de un sitio. Las solicitudes posteriores usan valores que los servidores front-end web almacenan en caché. Por lo tanto, no hay ninguna carga en la aplicación de servicio de metadatos administrados mientras los servidores front-end web satisfacen las solicitudes.
Caché de resultados de búsqueda anónima
La memoria caché de resultados de búsqueda anónima almacena los resultados de una consulta, los datos de refinamiento de dicha consulta y otras tablas de resultados que devuelve el servicio de caché distribuida de SharePoint. Cada entrada de caché depende de los parámetros de una consulta, como el orden de los resultados, los refinadores solicitados y cualquier regla de reordenación dinámica. La memoria caché afecta a todas las consultas que una aplicación web controla, incluidas las procedentes de elementos web de búsqueda y de clientes del CSOM. Para obtener más información, vea Información general sobre la arquitectura de búsqueda en SharePoint Server y La búsqueda a escala de sitios de Internet en SharePoint Server.
Por motivos de seguridad, esta memoria caché no se usa en consultas que se autentican.
A fin de obtener los mejores resultados, recomendamos configurar el servicio de caché distribuida para que se ejecute únicamente en el equipo donde se ejecutan las aplicaciones de servicio de SharePoint. No conviene ejecutar el servicio de caché distribuida en equipos con roles de servidor front-end web.
La memoria caché de resultados de búsqueda anónima actualiza los elementos cada 15 minutos de forma predeterminada. Puede usar Microsoft PowerShell para configurar la duración de la caché en la aplicación web donde está configurada la memoria caché:
$webapp.Properties["SearchResultsCacheTTL"] = <number of seconds to keep in cache>
$webapp.Update()
Si quiere que los resultados de búsqueda se actualicen con una frecuencia mayor que la del valor predeterminado, disminuya este valor. Tenga en cuenta que esto aumenta el número de consultas que el servicio de búsqueda debe atender.
Se recomienda usar siempre la memoria caché en las páginas de publicación que reciben tráfico intensivo. Algunos ejemplos de estos tipos de páginas son la página principal del sitio y las páginas de categorías que usan elementos web de búsqueda. No se recomienda almacenar en caché las páginas de elementos de catálogo. Dado que se tendría acceso a una página de elementos de catálogo individual con mucha menos frecuencia que una página principal, y es posible que no valga la pena almacenar el elemento en la memoria caché.
Cuando desactivamos la memoria caché de resultados de búsqueda anónima en nuestro entorno de prueba (con los mismos patrones de carga), los tiempos de respuesta del servidor aumentaron considerablemente, al tiempo que cayó el rendimiento en el número de vistas de página por segundo. A continuación mostramos un gráfico en el que se refleja esta relación:
Figura 5: Efectos de la memoria caché de resultados anónimos
Los elementos web de búsqueda de contenido están configurados de manera predeterminada para usar la memoria caché de resultados de búsqueda anónima. Los elementos web de reutilización de elementos del catálogo, que se usan en las páginas de elemento de catálogo, no están configurados para usarla, dados los patrones de escaso acceso que suelen caracterizar a estas páginas.
Para configurar el comportamiento de almacenamiento en caché para que un elemento web individual use (o no use) la caché de resultados de búsqueda anónima, establezca el valor de la subpropiedad "TryCache" en la DataProviderJSON propiedad del elemento web. Si el valor es "true", la consulta usa la memoria caché. Si el valor es "false", la consulta no usa la memoria caché para las consultas de búsqueda anónimas.
Efecto de la memoria caché de resultados
La memoria caché de resultados es una forma eficaz de reducir la carga en escenarios de publicación en SharePoint Server 2013. Para obtener más información sobre cómo funciona la memoria caché de resultados en este artículo, vea Almacenamiento en la memoria caché de resultados y los perfiles de memoria caché.
Una implementación de SharePoint puede beneficiarse del almacenamiento en caché de resultados para aliviar la carga en las bases de datos de contenido de SharePoint y la aplicación del servicio de búsqueda. A continuación indicamos algunas situaciones de ejemplo:
Recibe una gran cantidad de tráfico en algunas de las páginas.
Recibe mucho tráfico en las bases de datos de contenido SharePoint.
Los equipos que atienden consultas de búsqueda se están ejecutando con un elevado uso de CPU.
Se recomienda usar el almacenamiento en caché de resultados en las páginas del sitio que sean muy populares, como la página principal o algunas páginas de elementos que reciben un tráfico muy intenso.
Importante
Hay un problema conocido en SharePoint Server 2013 cuando las páginas que tienen habilitado el almacenamiento en caché de resultados contienen al mismo tiempo elementos web de búsqueda de contenido. Para evitar que este problema se produzca en su implementación, instale la actualización de SharePoint Server 2013 del 12 de marzo de 2013.
En el siguiente gráfico se muestran los resultados de nuestro entorno de pruebas, donde usamos el almacenamiento en caché de resultados en la página principal y en las páginas de categorías, que reciben el 60 por ciento del tráfico del sitio.
Figura 6: Efecto del almacenamiento en caché de resultados en la página principal y las páginas de categorías
Nota:
Los elementos web de búsqueda de contenido disponen de una opción de configuración para ejecutarse en modo asincrónico. El almacenamiento en caché de resultados no es válido en las cargas de los elementos web de búsqueda de contenido.
Procesamiento de análisis de uso
SharePoint Server 2013 procesa la información contenida en la base de datos de uso para tener información sobre los análisis de uso lista para utilizarse. En nuestra topología, el procesamiento de análisis tiene lugar en el nodo que contiene el nodo de administración de búsqueda, el servicio de caché distribuida y otras aplicaciones de servicio. Para obtener más información, vea Información general sobre el procesamiento de análisis en SharePoint Server.
Hemos tomado algunas mediciones de tiempo de procesamiento de análisis del sitio de publicación entre sitios que usamos en nuestras pruebas anteriores. Así, medimos el tiempo que SharePoint Server 2013 tarda en procesar una gran cantidad de eventos click en las páginas del sitio. Aunque estos resultados se derivan de un sitio de publicación entre sitios, son igualmente válidos en los sitios en los que se usa el método de publicación de creación en contexto.
En nuestras pruebas de procesamiento de análisis de uso, generamos los siguientes eventos ficticios durante todos los días a lo largo de una semana:
27,5 millones de eventos click repartidos entre 3 millones de elementos de lista y 400.000 usuarios.
Se usó la distribución de Zipf para que algunos elementos y usuarios tuvieran muchos eventos y otros, menos.
Esto generó un total de 7,5 millones de eventos al día, simulando a distintos usuarios que generaban diferentes patrones de tráfico en el sitio.
Se ha desencadenado que el análisis se ejecute siete veces para simular una semana de tráfico. Ejecutamos el trabajo análisis de uso todos los días para los datos que acumulamos durante seis días. Luego medimos la hora, el séptimo día tardó. El séptimo día será el día que más tarde en procesarse a medida que se procesen los elementos de la semana completa y se actualice el gráfico de relaciones. El tiempo de ejecución y el uso del disco para el día 8 serán similares al día 1.
El procesamiento de análisis no tuvo un impacto significativo en el equipo en el que se ejecutó, de modo que pudimos seguir atendiendo consultas y mantener el contenido actualizado en el sitio basado en búsquedas sin ningún problema.
En la siguiente tabla se resumen los resultados:
| Plan de pruebas | Actualización del gráfico de relaciones | Tiempo de ejecución (horas) | Uso máximo total de disco | Uso máximo de disco en el análisis de uso |
|---|---|---|---|---|
| Día 1 | No | 02:35 | 2,65 GB | |
| Día 2 | No | 02:43 | ||
| Día 3 | No | 03:23 | ||
| Día 4 | No | 04:39 | ||
| Día 5 | No | 06:08 | ||
| Día 6 | No | 07:35 | ||
| Día 7 | Sí | 08:29 | 82,4 GB | 4 GB |
En el siguiente gráfico se muestran los tiempos de ejecución de los diferentes días:
Figura 7: Horas de tiempo de ejecución por día
Publicación entre sitios con usuarios autenticados
La publicación de SharePoint se usa habitualmente en los sitios de una intranet. Al usar SharePoint Server 2013, estos sitios también permiten la publicación entre sitios. En las siguientes secciones nos centraremos en algunas diferencias importantes que se deben tener en cuenta al planear un sitio de publicación entre sitios con usuarios autenticados. Aparte de las excepciones contempladas en las siguientes secciones, los sitios de acceso para usuarios autenticados se siguen rigiendo por las reglas de los sitios a los que se accede de forma anónima.
Ausencia de caché de resultados de búsqueda anónima
Tal y como hemos mencionado en la sección Caché de resultados de búsqueda anónima anterior, esta memoria caché tiene efecto únicamente para los usuarios que acceden al sitio de SharePoint de forma anónima. Por lo tanto, la capacidad de rendimiento de los sitios a los que acceden los usuarios autenticados será notablemente inferior que los sitios a los que se accede anónimamente, en los que se usa la memoria caché de resultados de búsqueda anónima. Los sitios de intranet no suelen recibir cargas tan voluminosas como las que se señalaban en la sección anterior (de hasta 100 vistas de página por segundo). Con todo, se trata de una diferencia importante que conviene tener en cuenta.
Usar la memoria caché de resultados puede compensar en parte la imposibilidad de tener una memoria caché de resultados de búsqueda anónima en estos escenarios. En los sitios de los sitios de publicación entre sitios en los que esté previsto que se produzcan varias vistas de página por segundo se debería considerar habilitar la memoria caché de resultados.
Importante
Los elementos web de búsqueda de contenido cuentan con una opción que, si se habilita, hace que se ejecuten en modo asincrónico. La memoria caché de resultados no es válida en las cargas de los elementos web de búsqueda de contenido asincrónicos.
Índice de búsqueda más extenso
En función del tamaño de la empresa que implementa SharePoint Server 2013, las implementaciones de intranet para SharePoint Server 2013 suelen indexar un mayor número de documentos. Esto significa que la topología de búsqueda necesaria para indexar esos documentos será diferente en comparación con la topología descrita en la sección anterior. Consulte Planear la búsqueda en SharePoint Server para ajustar el tamaño de la implementación de SharePoint correctamente.
Publicación de creación en contexto
En esta sección se proporcionan directrices y resultados que usan SharePoint Server 2013, si bien no se entra a detallar las distintas características que afectan a la planeación de capacidad. Para obtener más información en esta área, vea Administración de contenido web en SharePoint Server.
Publicación de creación en contexto con usuarios anónimos
En nuestras pruebas, hemos trabajado con un sitio web que tiene las siguientes características:
Hasta 20.000 páginas de artículo divididas en 20 carpetas de 1.000 páginas a lo largo de 50 sitios de una colección de sitios.
Se usa la navegación estructurada.
Suele recibir un mínimo de entre 50 y 100 vistas de páginas por segundo.
Patrones de tráfico que llevan a la siguiente combinación de páginas:
20 páginas que contienen un solo elemento web de consulta de contenido que emite consultas de base de datos de contenido de diferentes ámbitos (20 por ciento del tráfico)
30 páginas que incluyen varios elementos web de consulta de contenido que emiten consultas de base de datos de contenido de diferentes ámbitos (30 por ciento del tráfico)
1.600 artículos con 40 KB de texto y dos imágenes (recibe el 50 por ciento del tráfico)
En el siguiente diagrama se refleja la topología de servidores recomendada:
Figura 8: Topología de prueba de publicación de creación en contexto
1 equipo que hospeda SQL Server
1 equipo que hospeda las aplicaciones de servicio de SharePoint como servidor front-end web
Resultados del entorno de pruebas
Utilizamos la topología mostrada en el diagrama anterior en nuestro entorno de pruebas con equipos físicos y una prueba de carga de Visual Studio Team System.
En la siguiente tabla se recogen las especificaciones técnicas que hemos usado en los equipos que hemos sometido a prueba:
| Componentes de servidor | Servidores de SharePoint |
|---|---|
| Procesadores | CPUs Intel Xeon a 2,33 GHz (2 procesadores, 8 núcleos en total, 8 subprocesos en total) |
| Memoria RAM | 24 GB |
| Sistema operativo | Windows Server 2008 R2 Enterprise, 64 bits |
| Número de adaptadores de red | 2 |
| Velocidad del adaptador de red | 1 Gbps |
| Autenticación | Ninguno: anónimo |
| Tipo de equilibrador de carga | Equilibrador de carga de software de Windows |
| Versión de software | SharePoint Server 2013 |
| Componentes de servidor | Servidor de bases de datos |
|---|---|
| Procesadores | CPUs Intel Xeon MP7130M a 2,79 GHz (2 procesadores, 8 núcleos en total, 16 subprocesos en total) |
| Memoria RAM | 16 GB |
| Sistema operativo | Windows Server 2008 R2 Enterprise, 64 bits |
| Matriz de discos | 2 Dell PERC 5/E |
| Número de adaptadores de red | 1 |
| Velocidad del adaptador de red | 1 gigabit o Gbps |
| Autenticación | NTLM |
| Versión de software | Microsoft SQL Server 2008 R2 SP1 |
En la siguiente tabla se muestran los resultados obtenidos de una ejecución de 10 minutos:
| Características de la prueba | Zona verde | Zona roja |
|---|---|---|
| Número de usuarios de VSTS: | 5 | 15 |
| Percentil 50 del tiempo de respuesta del servidor: | 69 ms | 112 ms |
| Percentil 95 del tiempo de respuesta del servidor: | 92 ms | 221 ms |
| Vistas de página por segundo: | 57 | 93 |
| Uso medio de CPU (servidor de aplicaciones y servidor front-end web) | 55 | 97 |
| CPU promedio (SQL Server) | 7 | 9 |
| Uso máximo de memoria (servidor de aplicaciones y servidor front-end web) | 8,9 GB | 8,9 GB |
Efecto de la memoria caché de resultados
La memoria caché de resultados es una forma eficaz de reducir la carga en escenarios de publicación en SharePoint Server 2013. Para obtener más información, vea Planear el almacenamiento en caché y el rendimiento en SharePoint Server.
En la siguiente tabla se recogen los resultados que obtuvimos en una ejecución de 10 minutos con la memoria caché de resultados habilitada y una proporción de aciertos del 90 por ciento:
| Características de la prueba | Zona verde | Zona roja |
|---|---|---|
| Número de usuarios de VSTS: | 5 | 15 |
| Percentil 50 del tiempo de respuesta del servidor: | 2 ms | 2 ms |
| Percentil 95 del tiempo de respuesta del servidor: | 74 ms | 88 ms |
| Vistas de página por segundo: | 190 | 418 |
| Uso medio de CPU (servidor de aplicaciones y servidor front-end web) | 58 | 85 |
| Uso medio de CPU (SQL Server) | 5 | 7 |
| Uso máximo de memoria (servidor de aplicaciones y servidor front-end web) | 9,2 GB | 9,4 GB |
Los resultados de la prueba arrojan que el uso del almacenamiento en la memoria caché de resultados puede disparar notablemente el rendimiento de un sitio de publicación de SharePoint, así como acortar los tiempos de respuesta del servidor. De hecho, los tiempos de respuesta fueron casi inmediatos en el caso de las solicitudes atendidas en la memoria caché de resultados.
En el siguiente gráfico se muestra un resumen de nuestros resultados de las pruebas:
Figura 9: Efecto del almacenamiento en la memoria caché de resultados con una proporción de aciertos en caché del 90%
Efecto de la navegación administrada
En SharePoint Server 2013, los sitios de publicación también pueden usar la navegación administrada. Para obtener más información sobre cómo configurarlo, vea Información general sobre la navegación administrada en SharePoint Server.
Ejecutamos el mismo conjunto de pruebas en nuestro sitio de prueba con navegación administrada tal y como lo hicimos con las pruebas de navegación estructurada. Las pruebas pusieron de manifiesto que no hay ninguna diferencia de rendimiento relevante cuando los sitios usaban la navegación administrada o la navegación estructurada.
| Características de la prueba | Zona verde | Zona roja |
|---|---|---|
| Número de usuarios de VSTS: | 5 | 15 |
| Percentil 50 del tiempo de respuesta del servidor: | 70 ms. | 111 ms. |
| Percentil 95 del tiempo de respuesta del servidor: | 95 ms | 215 ms |
| Vistas de página por segundo: | 56 | 94 |
| Uso medio de CPU (servidor de aplicaciones y servidor front-end web) | 54 | 97 |
| CPU promedio (SQL Server) | 7 | 9 |
| Uso máximo de memoria (servidor de aplicaciones y servidor front-end web) | 8 GB | 8 GB |
En el siguiente gráfico se muestran los distintos tipos de navegación en el mismo sitio:
Figura 10: Navegación administrada frente a navegación estructurada
Efecto de agregar más equipos (escalado horizontal)
Si encuentra que necesita más rendimiento de una implementación de SharePoint, el escalado horizontal (aumentando el número de equipos que hospedan SharePoint Server 2013) es una opción a tener en cuenta. En el siguiente gráfico se aprecia cómo el rendimiento va aumentando a medida que vamos agregando más equipos a la granja:
Figura 11: Efecto en el rendimiento de agregar más servidores front-end web
En nuestras pruebas aumentamos la carga en el servidor que ejecuta SharePoint Server 2013 para cada equipo que se agregó para que los tiempos de respuesta del servidor fueran aproximadamente los mismos (alrededor de 11 milisegundos para la zona verde, alrededor de 250 milisegundos para la zona roja).
Sitios de publicación de creación en contexto con usuarios autenticados
La característica de publicación de SharePoint se usa habitualmente en las intranets, donde los usuarios que acceden al sitio están autenticados. En esta sección incluimos las pruebas en las que se usaron usuarios autenticados y los efectos que esto produjo.
En la siguiente tabla se plasman los resultados de prueba de los sitios de publicación de creación en contexto a los que tuvieron acceso los usuarios autenticados mediante autenticación basada en notificaciones con NTLM. Observe que en estas pruebas se ha usado exactamente el mismo hardware que en las pruebas de la sección anterior.
| Características de la prueba | Zona verde | Zona roja |
|---|---|---|
| Número de usuarios de VSTS: | 5 | 15 |
| Percentil 50 del tiempo de respuesta del servidor: | 76 ms | 107 ms |
| Percentil 95 del tiempo de respuesta del servidor: | 103 ms | 194 ms |
| Vistas de página por segundo: | 54 | 100 |
| Uso medio de CPU (servidor de aplicaciones y servidor front-end web) | 50 | 97 |
| Uso medio de CPU (SQL Server) | 6 | 9 |
| Uso máximo de memoria (servidor de aplicaciones y servidor front-end web) | 9,5 GB | 9,5 GB |
Los números ponen de manifiesto que no hay una gran diferencia en cuanto a rendimiento y tiempos de respuesta del servidor entre las solicitudes anónimas y las solicitudes autenticadas.
En el siguiente gráfico se muestran los distintos tipos de solicitudes en el mismo sitio:
Figura 12: Solicitudes anónimas frente a solicitudes autenticadas
Efecto de la memoria caché de resultados en escenarios autenticados
Las solicitudes autenticadas en el servidor requieren una ida y una vuelta a la base de datos de contenido para asegurarse de que la cuenta que accede al contenido tiene permisos para verlo. Esto quiere decir que las características de rendimiento del almacenamiento en caché de resultados de los sitios autenticados son distintas de las de los sitios anónimos.
En la siguiente tabla se recogen los resultados que recibimos en una ejecución de 10 minutos con la memoria caché de resultados habilitada y una proporción de aciertos en caché del 90 por ciento:
| Características de la prueba | Zona verde | Zona roja |
|---|---|---|
| Número de usuarios de VSTS: | 6 | 18 |
| Percentil 50 del tiempo de respuesta del servidor: | 17 ms | 29 ms |
| Percentil 95 del tiempo de respuesta del servidor: | 87 ms | 118 ms |
| Vistas de página por segundo: | 114 | 236 |
| Uso medio de CPU (servidor de aplicaciones y servidor front-end web) | 50 | 97 |
| CPU promedio (SQL Server) | 7 | 10 |
| Uso máximo de memoria (servidor de aplicaciones y servidor front-end web) | 9,9 GB | 10 GB |
En el siguiente gráfico se muestra un resumen de estos resultados:
Figura 13: Efecto del almacenamiento en caché de resultados autenticado
Consulte también
Conceptos
Planear la administración de contenido web en SharePoint Server
Configuración de soluciones de administración de contenido web en SharePoint Server
Configuración de la caché para una aplicación web en SharePoint Server
Planear el almacenamiento en caché y el rendimiento en SharePoint Server