Estimación de los requisitos de rendimiento y capacidad para la búsqueda de SharePoint Server 2010

 

Se aplica a: SharePoint Server 2010

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

Resumen: en este artículo se proporciona información acerca de la planeación de capacidad para distintas implementaciones de búsqueda de Microsoft SharePoint Server 2010, incluidos los conjuntos o granjas de servidores de SharePoint Server 2010 pequeñas, medianas y grandes.

En este artículo se proporciona información de planeación de capacidad para implementaciones de entorno de colaboración de búsqueda de SharePoint Server 2010. Se incluye la siguiente información para tres ejemplos de configuraciones de granja de servidores de búsqueda:

• Especificaciones de entorno de pruebas como hardware, topología de granja de servidores y configuración

• La carga de trabajo usada para la generación de datos, incluido el número y la clase de usuarios, así como las características de uso de la granja de servidores

• Conjunto de datos de la granja de servidores de prueba, incluidos los tamaños y el contenido de las bases de datos

• Datos de mantenimiento y rendimiento específicos del entorno probado

Este artículo también contiene datos de prueba comunes y recomendaciones para determinar el hardware, la topología y la configuración necesarios para implementar un entorno similar y para optimizar el entorno para las características de rendimiento y capacidad adecuadas.

La búsqueda de SharePoint Server 2010 contiene un conjunto más rico de características y un modelo de topología más flexible que en las versiones anteriores. Antes de usar esta arquitectura para ofrecer funcionalidad y características más eficaces a los usuarios, debe considerar cuidadosamente el efecto sobre la capacidad y el rendimiento de la granja de servidores.

Después de leer este documento, sabrá cómo hacer lo siguiente:

• Definir objetivos de rendimiento y capacidad para el entorno.

• Planear el hardware necesario para admitir el número y tipo de usuarios, así como las características que se van a implementar.

• Diseñar la topología física y lógica para lograr una confiabilidad y eficacia óptimas.

• Probar, validar y escalar el entorno para lograr los objetivos de rendimiento y capacidad.

• Supervisar el entorno en lo que respecta a los indicadores clave.

Antes de leer este artículo, debería estar familiarizado con lo siguiente:

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

• Administración de capacidad de SharePoint Server 2010: Límites y límites máximos del software

• Disponibilidad

• Redundancia

• Contenido específico de la base de datos

Información general sobre la planeación

Los escenarios de este artículo describen granjas de servidores de prueba pequeñas, medianas y grandes, con hipótesis que pueden ayudarlo a empezar a planear la capacidad correcta de la granja de servidores. Estos tamaños de granja de servidores son aproximaciones que se basan en las siguientes hipótesis:

• Los repositorios rastreados son principalmente contenido de SharePoint Server.

• La mayoría de las consultas de usuario se pueden encontrar en el mismo 33% del índice. Esto significa que la mayoría de los usuarios consultan los mismos términos.

• Se usa la configuración predeterminada de metadatos, lo que garantiza que la base de datos de propiedades no crezca a gran velocidad.

• En granjas de servidores grandes y medianas, existen destinos de rastreo dedicados (servidores front-end web) que pueden servir contenido a los componentes de rastreo de estas granjas de servidores de búsqueda.

• Las medidas efectuadas en estas granjas de servidores pueden variar debido a las condiciones del entorno y de la red, y pueden tener hasta un margen de 10% de error.

Selección de un escenario

Para elegir el escenario correcto, tenga en cuenta las siguientes preguntas:

• Tamaño del corpus ¿Cuánto contenido tiene que permitir búsquedas? El número total de elementos debe contener todos los objetos, incluidos documentos, páginas web, elementos de lista y personas.

• Disponibilidad ¿Cuáles son los requisitos de disponibilidad? ¿Necesitan los clientes una solución de búsqueda que puede sobrevivir al error de un servidor concreto?

• Actualización de contenido ¿Cómo de actualizados desea que estén los resultados de la búsqueda? ¿Cuánto tiempo después de que un usuario cambia el contenido desea que las búsquedas proporcionen el contenido actualizado en los resultados? ¿Con qué frecuencia espera que el contenido cambie?

• Rendimiento ¿Cuántas personas buscarán en el contenido al mismo tiempo? Esto incluye a las personas que escriben en un cuadro de consulta, las consultas ocultas como elementos web que buscan datos automáticamente o los conectores sociales de Microsoft Outlook 2010 que solicitan fuentes de actividades que contienen direcciones URL que necesitan el recorte de seguridad desde el sistema de búsqueda.

Según las respuestas a estas preguntas, elija uno de los siguientes escenarios:

• Granja de servidores pequeña   Incluye una aplicación de servicio de búsqueda única que comparte algunos recursos en una sola granja de servidores de SharePoint Server. Típica para las implementaciones pequeñas, la cantidad de contenido para la que se proporciona la búsqueda es limitada (menos de 10 millones de elementos). Según los objetivos de actualización deseados, podrían producirse rastreos incrementales durante las horas laborables.

• Granja de servidores mediana   Incluye una o más aplicaciones de servicio de búsqueda en una granja dedicada, que proporcionan servicios de búsqueda a otras granjas de servidores. La cantidad de contenido para la que se proporciona la búsqueda es moderada (hasta 40 millones de elementos) y, para cumplir los objetivos de actualización, es probable que se produzcan rastreos incrementales durante las horas laborables.

• Granja de servidores grande   Incluye una o más aplicaciones de servicio de búsqueda en una granja dedicada, lo que proporciona servicios de búsqueda a otras granjas de servidores. La cantidad de contenido para la que se proporciona la búsqueda es grande (hasta 100 millones de elementos) y, para cumplir los objetivos de actualización, es probable que se produzcan rastreos incrementales durante las horas laborables.

Ciclo de vida de búsqueda

Estos tres escenarios permiten estimar la capacidad en una fase temprana de la granja de servidores. Las granjas pasan por las siguientes fases del ciclo de vida de búsqueda a medida que se rastrea el contenido:

• Adquisición de índices   Se trata de la primera fase del rellenado de datos. La duración de esta fase depende del tamaño de los orígenes de contenido. Se caracteriza por lo siguiente:

  • Rastreos completos (posiblemente simultáneos) de contenido.

  • Supervisión detallada del sistema de rastreo para comprobar que los hosts que se están rastreando no constituyen un cuello de botella para el rastreo.

  • Combinaciones maestras frecuentes que, para cada componente de consulta, se desencadenan cuando se ha modificado determinada cantidad del índice.

• Mantenimiento de índices   Se trata de la fase más común de una granja de servidores. Se caracteriza por lo siguiente:

  • Hay rastreos incrementales de todo el contenido.

  • Para los rastreos de contenido de SharePoint Server, la mayoría de los cambios que se producen durante el rastreo son cambios de seguridad.

  • Hay combinaciones maestras poco frecuentes que, para cada componente de consulta, se desencadenan cuando se ha modificado determinada cantidad del índice.

• Limpieza del índice   Esta fase se produce cuando un cambio de contenido saca a la granja de servidores de la fase de mantenimiento de índices; por ejemplo, cuando un sitio o una base de datos de contenido se mueve de una aplicación de servicio de búsqueda a otra. Esta fase se desencadena cuando se produce cualquiera de las siguientes acciones:

  • El rastreador de búsqueda no encuentra un host que está proporcionando contenido durante un período de tiempo prolongado.

  • Una dirección de inicio u origen de contenido se elimina de una aplicación de servicio de búsqueda.

Escenarios

En esta sección se describen las configuraciones que se usaron para los escenarios de granja de servidores pequeña, mediana y grande. También se incluye la carga de trabajo, el conjunto de datos, los datos de rendimiento y datos de prueba para cada entorno.

Granja de servidores pequeña

Dado que la granja de servidores es pequeña, algunos de los servidores deben desempeñar varios roles. Se recomienda combinar un componente de consulta con un servidor front-end web para evitar colocar componentes de rastreo y de consulta en el mismo servidor. Esta configuración usa tres servidores de aplicaciones y un servidor de bases de datos, tal como se indica a continuación:

• Como generalmente se sugieren servidores de consultas redundantes para la búsqueda empresarial, se usaron dos servidores de aplicaciones para los componentes de consulta, dada la siguiente configuración:

  • Un servidor de aplicaciones también hospeda el Centro de búsqueda. Esta configuración puede omitirse si la granja de servidores pequeña se usa como granja de servicio, y los centros de búsqueda se crean en granjas de contenido secundarias que usen la aplicación de servicio de búsqueda de esta granja de servicio primaria.

  • La configuración de consulta preferida para menos de 10 millones de elementos es tener una partición de índice. Cada servidor tiene un componente de consulta principal de la partición del índice. Esta configuración del componente de consulta activo/activo permite el error de uno de los componentes de consulta, al mismo tiempo que mantiene la capacidad para atender consultas desde el componente de consulta restante. Si se produce un error en un componente de consulta, la búsqueda envía consultas (round robin) al siguiente componente de consulta disponible.

• Un servidor de aplicaciones utilizado para la administración y el rastreo. Esto significa que la Administración central, el componente de administración de búsqueda y un componente de rastreo se crean en este servidor.

• Un solo servidor de bases de datos para servir de apoyo para la granja de servidores. El servidor de bases de datos debe tener un número dedicado de operaciones de entrada y salida por segundo (IOPS) para las bases de datos de administración, propiedades y rastreo (por ejemplo, use diferentes matrices de almacenamiento).

Especificaciones

En esta sección se ofrece información detallada sobre el hardware, el software, la topología y la configuración del entorno de prueba.

Topología

Hardware

Nota

Debido a que la granja de servidores de prueba estaba ejecutando versiones preliminares de SharePoint Server 2010 y el equipo deseaba evitar posibles problemas, el hardware que se usó para los servidores tenía más capacidad de la que se necesita normalmente.

Servidores web

Servidor web	Servidor front-end web/consulta (1)
Procesador	1 procesador de núcleo cuádruple a 3 GHz
RAM	16 GB
Sistema operativo	Windows Server 2008 R2 de 64 bits
Almacenamiento	2 SAS de 450 GB a 15.000 rpm: RAID 1: SO 2 SAS de 450 GB a 15.000 rpm: RAID 1: Datos 1 2 SAS de 450 GB a 15.000 rpm: RAID 1: Datos 2
Número de tarjetas de interfaz de red (NIC)	2
Velocidad de tarjetas de interfaz de red	1 gigabit
Autenticación	NTLM
Tipo de equilibrador de carga	Ninguno
Versión de software	SharePoint Server 2010 (versión preliminar)
Servicios que se ejecutan localmente	Todos los servicios (incluido el de configuración del sitio y consulta de búsqueda)

Servidores de aplicaciones

Servidor	Consulta (1)	Rastreo y administración (1)
Procesador	1 procesador de núcleo cuádruple a 3 GHz	1 procesador de núcleo cuádruple a 3 GHz
RAM	16 GB	16 GB
Sistema operativo	Windows Server 2008 R2 de 64 bits	Windows Server 2008 R2 de 64 bits
Almacenamiento	2 SAS de 450 GB a 15.000 rpm: RAID 1: SO 2 SAS de 450 GB a 15.000 rpm: RAID 1: Datos 1 2 SAS de 450 GB a 15.000 rpm: RAID 1: Datos 2	2 SAS de 450 GB a 15.000 rpm: RAID 1: SO 2 SAS de 450 GB a 15.000 rpm: RAID 1: Temporal 2 SAS de 450 GB a 15.000 rpm: RAID 0: Datos
Número de tarjetas de interfaz de red	1	1
Velocidad de tarjetas de interfaz de red	1 gigabit	1 gigabit
Autenticación	NTLM	NTLM
Tipo de equilibrador de carga	Ninguno	Ninguno
Versión de software	SharePoint Server 2010 (versión preliminar)	SharePoint Server 2010 (versión preliminar)
Servicios que se ejecutan localmente	Búsqueda de SharePoint Server; Servicio de configuración del sitio y consulta de búsqueda	Búsqueda de SharePoint Server

Servidores de bases de datos

Base de datos	Compartida (1)
Procesador	2 procesadores de núcleo cuádruple a 3 GHz
RAM	16 GB
Sistema operativo	Windows Server 2008 R2 de 64 bits
Almacenamiento	2 SAS de 450 GB a 15.000 rpm: RAID 1: SO 2 SAS de 450 GB a 15.000 rpm: RAID 0: Datos 2 SAS de 450 GB a 15.000 rpm: RAID 0: Registros Nota Debido al número reducido de unidades, el procedimiento recomendado de segregar las bases de datos en diferentes canales de E/S no era aplicable.
Número de tarjetas de interfaz de red	2
Velocidad de tarjetas de interfaz de red	1 gigabit
Autenticación	NTLM
Versión de software	Microsoft SQL Server 2008 Enterprise

Carga de trabajo

En esta sección se describe la carga de trabajo que se usó para la generación de datos, incluido el número de usuarios y las características de uso de la granja de servidores.

Características de la carga de trabajo	Valor
Descripción de alto nivel de la carga de trabajo	Granjas de servidores de búsqueda
Promedio de consultas por minuto	6
Promedio de usuarios simultáneos	1
Número total de consultas por día	8.640

Conjunto de datos

En esta sección se describe el conjunto de datos de la granja de servidores de prueba, incluidos el contenido y el tamaño de las bases de datos, los índices de búsqueda y los orígenes de datos externos.

Objeto	Valor
Tamaño de índice de búsqueda (cantidad de elementos)	9 millones
Tamaño de la base de datos de rastreo	52 GB
Tamaño del archivo de registro de la base de datos de rastreo	11 GB
Tamaño de la base de datos de propiedades	68 GB
Tamaño del archivo de registro de la base de datos de propiedades	1 GB
Tamaño de la base de datos de administración de búsqueda	2 GB
Tamaño de las particiones de índice activas	38,4 GB (76,8 GB en total, porque se refleja el índice)
Número total de bases de datos de búsqueda	3
Otras bases de datos	SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

Datos de mantenimiento y rendimiento

En esta sección se proporcionan los datos de mantenimiento y rendimiento específicos del entorno de prueba.

Datos de rendimiento de consultas

Las siguientes medidas se tomaron con 9 millones de elementos en el índice. Las columnas ofrecen las medidas que se tomaron durante la prueba específica, y los resultados están en la parte inferior de la tabla siguiente. Las medidas se describen de la siguiente forma:

• Latencia de consulta   Estas medidas se tomaron durante una prueba de latencia de consulta, en la que una herramienta de prueba envió un conjunto de consultas estándar, como un usuario, y después midió la latencia resultante. No hubo rastreos en curso durante la prueba.

• Rendimiento de consulta   Estas medidas se tomaron durante una prueba de rendimiento de consulta, en la que una herramienta de prueba envió un conjunto de consultas estándar a la granja de servidores, como un número creciente de usuarios (hasta 80) y, a continuación, midió el rendimiento y la latencia resultantes. No hubo rastreos en curso durante la prueba.

	Métrica de cuadro de mandos	Latencia de consulta	Rendimiento de consulta
Métricas de CPU	CPU de SQL Server promedio	3,4%	12%
	CPU de servidor front-end web promedio	8%	51%
	CPU de servidor de consultas promedio	13,3%	95%
Confiabilidad	Frecuencia de errores	0	0
	Bloqueos de servidores front-end web	0	0
	Bloqueos de servidores de aplicaciones	0	0
SQL Server	Frecuencia de aciertos de caché (SQL Server)	99,97%	100%
	Bloqueos de SQL Server: tiempo promedio de espera (ms)	0,071	0,038
	Bloqueos de SQL Server: tiempo de espera de bloqueos (ms)	0,035	0,019
	Bloqueos de SQL Server: interbloqueos por segundo	0	0
	Bloqueos temporales de SQL Server: tiempo promedio de espera (ms)	31	0,017
	Compilaciones de SQL Server/s	14,9	10,2
	Estadísticas de SQL Server: recompilaciones de SQL Server/s	0,087	0,05
	Promedio de longitud de la cola de disco (SQL Server)	0,011	0,01
	Longitud de cola de disco: escrituras (SQL Server)	0,01	0,008
	Lecturas de disco/s (SQL Server)	0,894	0,05
	Escrituras en disco/s (SQL Server)	45	106
Servidor de aplicaciones	Promedio de longitud de la cola de disco (servidor de consultas)	0,013	0,001
	Longitud de cola de disco: escrituras (servidor de consultas)	0	0,001
	Lecturas de disco/s (servidor de consultas)	11,75	0,06
	Escrituras en disco/s (servidor de consultas)	4	5,714
	Promedio de memoria usada (servidor de consultas)	8,73%	9%
	Máximo de memoria usada (servidor de consultas)	8,75%	9%
Servidor front-end web	Solicitudes de ASP.NET en cola (promedio de todos los servidores front-end web)	0	0
	Promedio de memoria usada (servidor front-end web)	9,67%	95%
	Máximo de memoria usada (servidor front-end web)	9,74%	100%
Resultados de las pruebas	Cantidad de operaciones correctas	1.757	13.608
	Número de errores	0	0
	Latencia de interfaz de usuario de consultas (percentil 75)	0,331 segundos	3,68 segundos
	Latencia de interfaz de usuario de consultas (percentil 95)	0,424 segundos	3,93 segundos
	Rendimiento de consulta	3,29 solicitudes por segundo	22,4 solicitudes por segundo

Datos de rendimiento del rastreo

Las siguientes medidas se tomaron durante los rastreos completos, secuenciales e iniciales del origen de contenido determinado. El tamaño del origen de contenido se expresa en millones de elementos. Las columnas ofrecen las medidas tomadas durante el rastreo específico y los resultados están en la parte inferior de la tabla.

	Métrica de cuadro de mandos	Contenido de SharePoint (4 millones)	Recurso compartido de archivos (1 millón)	HTTP (no de SharePoint) (1 millón)
Métricas de CPU	CPU de SQL Server promedio	5,4%	11,7%	23%
	CPU de indizador promedio	41,6%	69%	71%
Confiabilidad	Frecuencia de errores	0	0	0
	Bloqueos de servidores front-end web	0	0	0
	Bloqueos de servidores de aplicaciones	0	0	0
SQL Server	Frecuencia de aciertos de caché (SQL Server)	no disponible	no disponible	no disponible
	Bloqueos de SQL Server: tiempo promedio de espera (ms)	436	51,76	84,73
	Bloqueos de SQL Server: tiempo de espera de bloqueos (ms)	no disponible	no disponible	no disponible
	Bloqueos de SQL Server: interbloqueos por segundo	no disponible	no disponible	no disponible
	Bloqueos temporales de SQL Server: tiempo promedio de espera (ms)	1,05	1,64	3,53
	Compilaciones de SQL Server/s	no disponible	no disponible	no disponible
	Estadísticas de SQL Server: recompilaciones de SQL Server/s	no disponible	no disponible	no disponible
	Promedio de longitud de la cola de disco (SQL Server)	27,124	6,85	45
	Longitud de cola de disco: escrituras (SQL Server)	17,6	6,7	21,57
Servidor de aplicaciones	Promedio de longitud de la cola de disco (servidor de rastreo)	0,008	0,032	0,02
	Longitud de cola de disco: escrituras (servidor de rastreo)	0,006	0,025	0,012
	Promedio de memoria usada (servidor de rastreo)	14,16%	10,4%	11,5%
	Máximo de memoria usada (servidor de rastreo)	19,2%	11,13%	12,78%
Servidor front-end web	Solicitudes de ASP.NET en cola (promedio de todos los servidores front-end web)	0	0	0
	Promedio de memoria usada (servidor front-end web)	no disponible	no disponible	no disponible
	Máximo de memoria usada (servidor front-end web)	no disponible	no disponible	no disponible
Resultados de las pruebas	Cantidad de operaciones correctas	3.934.881	1.247.838	996.982
	Número de errores	9.645	302	2
	Velocidad de rastreo del portal (elementos por segundo)	46,32	120,436	138,316
	Velocidad de rastreo del delimitador (elementos por segundo)	5.197	3.466,219	2.192,982
	Velocidad de rastreo total (elementos por segundo)	45,91	116,392	130,086

Datos de prueba

En esta sección se proporcionan datos de prueba que ilustran el rendimiento de la granja de servidores. Consulte la sección Optimizaciones más adelante en este artículo para saber cómo mejorar el rendimiento de la granja de servidores.

Latencia de consulta

En el siguiente gráfico se muestran los percentiles de latencia de consulta para esta granja de servidores a medida que aumenta la carga de usuarios (recopilados durante la prueba de rendimiento de consulta). Un percentil de consulta del 95% significa que el 95% de las latencias de consulta que se midieron se encontraban por debajo de ese valor.

En este gráfico se puede ver que, con un índice más pequeño, esta granja de servidores puede mantener una latencia de consulta de fracciones de segundo, incluso a medida que más usuarios simultáneos (20) realicen consultas en esta granja de servidores.

Rendimiento de consulta

En el siguiente gráfico se muestra el rendimiento de consulta para esta granja de servidores a medida que aumenta la carga de usuarios (recopilado durante la prueba de rendimiento de consulta).

Si tiene en cuenta los dos gráficos anteriores, puede ver que al agregar carga de usuarios de más de unos 20 usuarios simultáneos, esta granja de servidores no obtendrá más rendimiento de consulta y la latencia aumentará.

Tasa de rastreo

En el siguiente gráfico se muestra la tasa de rastreo para esta granja de servidores durante la fase de adquisición de índices del ciclo de vida de búsqueda. Los valores representan un rastreo completo, en elementos rastreados por segundo.

La sobrecarga extra implicada para realizar un rastreo completo de manera eficaz en un origen de contenido de sitio de SharePoint tiene como resultado una tasa menor de rastreo global en esta granja de servidores.

Conclusión general

Esta granja de servidores estaba cerca de la capacidad de memoria RAM para los servidores de consultas. Puesto que los procesos del servidor front-end web (que también consumen RAM) estaban también en uno de los servidores de consultas, la latencia en las consultas que se ejecutan en ese servidor se vería afectada.

A continuación, se indican los pasos para mejorar el rendimiento de esta granja de servidores:

• Mueva los procesos del servidor front-end web a su propio servidor front-end web (es decir, agregue otro servidor front-end web para conseguir redundancia).

• Agregue más RAM a los dos servidores de consultas. Se recomienda suficiente RAM en el servidor de consultas para el 33% de la partición de índice del componente de consulta activo, además de 3 GB para el sistema operativo y otros procesos.

• Agregue matrices de almacenamiento para poder segregar bases de datos en el servidor de bases de datos.

Granja de servidores mediana

La configuración de granja de servidores mediana usa un servidor web, seis servidores de aplicaciones y dos servidores de bases de datos, tal como se indica a continuación:

• Se usó un servidor web en esta configuración de prueba para hospedar el Centro de búsqueda. Se puede omitir este servidor web si las búsquedas se realizan siempre desde una granja de servidores secundaria mediante un proxy de aplicación de servicio de búsqueda (instalado en la granja secundaria). De lo contrario, probablemente deba agregar otro servidor web a esta granja de servidores para conseguir redundancia.

• Se usan dos servidores de aplicaciones para la administración y el rastreo. Esto significa lo siguiente:

  • Administración central y el componente de administración de búsqueda se crean en uno de los servidores de aplicaciones.

  • Cada servidor tiene dos componentes de rastreo. Cada componente de rastreo se adjunta a una base de datos de rastreo diferente para conseguir redundancia.

• Los cuatro servidores de aplicaciones restantes se usan para la consulta. Para hasta 40 millones de elementos, la configuración estándar es tener cuatro particiones de índice. La funcionalidad de consulta redundante se consigue al organizar los componentes de consulta para que cada servidor tenga un componente de consulta activo de una de las particiones de índice y un componente de consulta de conmutación por error de una partición de índice diferente. Sin embargo, esta granja de servidores de ejemplo muestra qué hacer si piensa tener más de 40 millones de elementos. Empiece con ocho particiones de índice (cada una con sus propios componentes de consulta activos y de conmutación por error) en los cuatro servidores de aplicaciones para que pueda minimizar la repartición de índice. Se da por sentado que cada servidor cumple las siguientes instrucciones para permitir los cuatro componentes en el mismo servidor de aplicaciones:

  • Hay suficiente memoria RAM y IOPS.

  • Cada servidor tiene más de seis núcleos de CPU para admitir el procesamiento de la manera siguiente:

    • Cuatro núcleos de CPU para los dos componentes de consulta activos.

    • Dos núcleos de CPU para los dos componentes de consulta de conmutación por error.

• Dos servidores de bases de datos sirven de apoyo para la granja de servidores. Un servidor de bases de datos se usa para las dos bases de datos de rastreo. El otro servidor se usa para las bases de datos de administración de búsqueda y propiedades, además de para las otras bases de datos de SharePoint. Los servidores de bases de datos deben tener un número dedicado de IOPS para cada base de datos de administración de búsqueda, propiedades y rastreo (por ejemplo, use matrices de almacenamiento diferentes).

Especificaciones

En esta sección se ofrece información detallada sobre el hardware, el software, la topología y la configuración del entorno de prueba.

Topología

Hardware

Nota

Debido a que la granja de servidores de prueba estaba ejecutando versiones preliminares de SharePoint Server 2010 y el equipo deseaba evitar posibles problemas, el hardware que se usó para los servidores tenía más capacidad de la que se necesita normalmente.

Servidor web

Servidor web	Servidor front-end web (1)
Procesador	2 procesadores de núcleo cuádruple a 2,33 GHz
RAM	8 GB
Sistema operativo	Windows Server 2008 R2 de 64 bits
Almacenamiento	2 SAS de 148 GB a 15.000 rpm: RAID 1: SO
Número de tarjetas de interfaz de red	2
Velocidad de tarjetas de interfaz de red	1 gigabit
Autenticación	NTLM
Tipo de equilibrador de carga	Ninguno
Versión de software	Microsoft SharePoint Server (versión preliminar)
Servicios que se ejecutan localmente	Todos los servicios

Servidores de aplicaciones

Hay seis servidores de aplicaciones en la granja de servidores. Se usan cuatro servidores para atender consultas y dos servidores para el rastreo.

Servidor (recuento)	Consulta (4)	Rastreo (1), rastreo y administración (1)
Procesador	2 procesadores de núcleo cuádruple a 2,33 GHz	2 procesadores de núcleo cuádruple a 2,33 GHz
RAM	32 GB	8 GB
Sistema operativo	Windows Server 2008 R2 de 64 bits	Windows Server 2008 R2 de 64 bits
Almacenamiento	2 SAS de 148 GB a 15.000 rpm: RAID 1: SO 4 SAS de 300 GB a 15.000 rpm: RAID 10: Datos	2 SAS de 148 GB a 15.000 rpm: RAID 1: SO y datos
Número de tarjetas de interfaz de red	2	2
Velocidad de tarjetas de interfaz de red	1 gigabit	1 gigabit
Autenticación	NTLM	NTLM
Tipo de equilibrador de carga	Ninguno	Ninguno
Versión de software	SharePoint Server 2010 (versión preliminar)	SharePoint Server 2010 (versión preliminar)
Servicios que se ejecutan localmente	Búsqueda de SharePoint Server; Servicio de configuración del sitio y consulta de búsqueda	Búsqueda de SharePoint Server

Servidores de bases de datos

Hay dos servidores de bases de datos. El primer servidor contiene las bases de datos de administración de búsqueda, propiedades y otras bases de datos de SharePoint Server. El segundo servidor contiene las dos bases de datos de rastreo. Tenga en cuenta que los volúmenes de almacenamiento que se crearon optimizaron el hardware existente que estaba disponible para la prueba.

Servidor de bases de datos	Bases de datos de SharePoint, de propiedades y de administración de búsqueda	Bases de datos de rastreo
Procesador	2 procesadores de núcleo cuádruple a 3,2 GHz	4 procesadores de doble núcleo a 2,19 GHz
RAM	32 GB	16 GB
Sistema operativo	Windows Server 2008 R2 de 64 bits	Windows Server 2008 R2 de 64 bits
Almacenamiento	2 SAS de 148 GB a 15.000 rpm: RAID 1: SO 2 SAS de 148 GB a 15.000 rpm: RAID 1: Registro temporal 2 SAS de 450 GB a 15.000 rpm: RAID 1: BD temporal 6 SAS de 450 GB a 15.000 rpm: RAID 10: BD de propiedades 2 SAS de 450 GB a 15.000 rpm: RAID 1: DB de administración de búsqueda y de SharePoint 2 SAS de 450 GB a 15.000 rpm: RAID 1: Registros	2 SAS de 148 GB a 15.000 rpm: RAID 1: SO 2 SAS de 148 GB a 15.000 rpm: RAID 1: Registro temporal 2 SAS de 300 GB a 15.000 rpm: RAID 1: DB temporal 6 SAS de 146 GB a 15.000 rpm: RAID 10: DB de rastreo 1 6 SAS de 146 GB a 15.000 rpm: RAID 10: DB de rastreo 2 2 SAS de 300 GB a 15.000 rpm: RAID 1: Registro de BD de rastreo 1 2 SAS de 300 GB a 15.000 rpm: RAID 1: Registro de BD de rastreo 2
Número de tarjetas de interfaz de red	2	2
Velocidad de tarjetas de interfaz de red	1 gigabit	1 gigabit
Autenticación	NTLM	NTLM
Versión de software	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

Carga de trabajo

En esta sección se describe la carga de trabajo que se usó para la generación de datos, incluido el número de usuarios y las características de uso de la granja de servidores.

Características de la carga de trabajo	Valor
Descripción de alto nivel de la carga de trabajo	Granjas de servidores de búsqueda
Promedio de consultas por minuto	12
Promedio de usuarios simultáneos	1
Número total de consultas por día	17.280
Trabajos del temporizador	Control de estado de búsqueda: eventos de rastreo; Informe de registro de rastreo; Trabajo de análisis de mantenimiento; Buscar y procesar

Conjunto de datos

En esta sección se describe el conjunto de datos de la granja de servidores de prueba, incluidos el contenido y el tamaño de las bases de datos, los índices de búsqueda y los orígenes de datos externos.

Objeto	Valor
Tamaño de índice de búsqueda (cantidad de elementos)	46 millones
Tamaño de la base de datos de rastreo	356 GB
Tamaño del archivo de registro de la base de datos de rastreo	85 GB
Tamaño de la base de datos de propiedades	304 GB
Tamaño del archivo de registro de la base de datos de propiedades	9 GB
Tamaño de la base de datos de administración de búsqueda	5 GB
Tamaño de las particiones de índice activas	316 GB (79 GB por componente activo).
Número total de bases de datos	4
Otras bases de datos	SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

Datos de mantenimiento y rendimiento

En esta sección se proporcionan los datos de mantenimiento y rendimiento específicos del entorno de prueba.

Datos de rendimiento de consulta

Las siguientes medidas se tomaron con 46 millones de elementos en el índice de búsqueda. Las columnas ofrecen las medidas que se tomaron durante la prueba específica, y los resultados están en la parte inferior de la tabla. Las medidas se describen de la siguiente forma:

• Latencia de consulta   Estas medidas se tomaron durante una prueba de latencia de consulta, en la que una herramienta de prueba envió un conjunto de consultas estándar, como un usuario, y después midió la latencia resultante. No hubo rastreos en curso durante la prueba.

• Rendimiento de consulta   Estas medidas se tomaron durante una prueba de rendimiento de consulta, en la que una herramienta de prueba envió un conjunto de consultas estándar a la granja de servidores, como un número creciente de usuarios (hasta 80) y, a continuación, midió el rendimiento y la latencia resultantes. No hubo rastreos en curso durante la prueba.

	Métrica de cuadro de mandos	Latencia de consulta	Rendimiento de consulta
Métricas de CPU	CPU de SQL Server promedio (servidor de bases de datos de propiedades)	5%	98%
	CPU de servidor front-end web promedio	3%	33%
	CPU de servidor de consultas promedio	3%	47%
Confiabilidad	Frecuencia de errores	0,07%	0%
	Bloqueos de servidores front-end web	0	0
	Bloqueos de servidores de aplicaciones	0	0
SQL Server (servidor de bases de datos de propiedades)	Frecuencia de aciertos de caché (SQL Server)	100%	99,9%
	Bloqueos de SQL Server: tiempo promedio de espera (ms)	0,000	0,159
	Bloqueos de SQL Server: tiempo de espera de bloqueos (ms)	0,000	0,080
	Bloqueos de SQL Server: interbloqueos por segundo	0	0
	Bloqueos temporales de SQL Server: tiempo promedio de espera (ms)	0,041	1,626
	Compilaciones de SQL Server/s	9,776	93,361
	Estadísticas de SQL Server: recompilaciones de SQL Server/s	0,059	0,071
	Tasa de lectura y escritura (E/S por base de datos)	0,01	0,81
	Promedio de longitud de la cola de disco (SQL Server)	0,001	0,037
	Longitud de cola de disco: escrituras (SQL Server)	0,000	0,003
	Lecturas de disco/s (SQL Server)	0,057	14,139
	Escrituras en disco/s (SQL Server)	4,554	17,515
Servidor de aplicaciones	Promedio de longitud de la cola de disco (servidor de consultas)	0,000	0,001
	Longitud de cola de disco: escrituras (servidor de consultas)	0,000	0,001
	Lecturas de disco/s (servidor de consultas)	0,043	0,266
	Escrituras en disco/s (servidor de consultas)	4,132	5,564
	Promedio de memoria usada (servidor de consultas)	9%	10%
	Máximo de memoria usada (servidor de consultas)	9%	10%
Servidor front-end web	Solicitudes de ASP.NET en cola (promedio de todos los servidores front-end web)	0	0
	Promedio de memoria usada (servidor front-end web)	47%	48%
	Máximo de memoria usada (servidor front-end web)	47%	49%
Resultados de las pruebas	Cantidad de operaciones correctas	1.398	14.406
	Número de errores	1	0
	Latencia de interfaz de usuario de consultas (percentil 75)	0,47 segundos	2,57 segundos
	Latencia de interfaz de usuario de consultas (percentil 95)	0,65 segundos	3,85 segundos
	Rendimiento de consulta	2,38 solicitudes por segundo	27,05 solicitudes por segundo

Datos de rendimiento del rastreo

Las siguientes medidas se tomaron durante los rastreos completos iniciales del origen de contenido determinado. El tamaño del origen de contenido se expresa en millones de elementos. Las columnas ofrecen las medidas tomadas durante el rastreo específico y los resultados están en la parte inferior de la tabla.

	Métrica de cuadro de mandos	Contenido de SharePoint (3,5 millones)	Recurso compartido de archivos (1 millón)	HTTP (no de SharePoint) (1 millón)
Métricas de CPU	CPU de SQL Server promedio (servidor de bases de datos de rastreo, servidor de bases de datos de propiedades)	11%, 19%	22%, 7%	23%, 5%
	CPU de SQL Server máxima (servidor de bases de datos de rastreo, servidor de bases de datos de propiedades)	96%, 100%	86%, 45%	79%, 28%
	CPU de indizador promedio	41,6%	69%	71%
Confiabilidad	Frecuencia de errores	0,2%	0,02%	0%
	Bloqueos de servidores front-end web	0	0	0
	Bloqueos de servidores de aplicaciones	0	0	0
SQL Server (servidor de bases de datos de rastreo, servidor de bases de datos de propiedades)	Frecuencia de aciertos de caché (SQL Server)	99,5%, 99,8%	No recopilado	99,9%, 99,3%
	Bloqueos de SQL Server: tiempo promedio de espera [ms]	1.881,749, 1.106,314	1.617,980, 2,882	983,137, 0,904
	Bloqueos de SQL Server: tiempo máximo de espera [ms]	69.919,500, 1.081.703	55.412,000, 304,500	24.000,500, 47
	Bloqueos de SQL Server: tiempo promedio de espera de bloqueos [ms]	339,658, 10.147,012	No recopilado	739,232, 0,136
	Bloqueos de SQL Server: tiempo máximo de espera de bloqueos [ms]	598.106,544, 234.708.784	No recopilado	52.711,592, 23,511
	Bloqueos de SQL Server: interbloqueos por segundo	0,001, 0	No recopilado	0,008, 0
	Bloqueos temporales de SQL Server: tiempo promedio de espera [ms]	2,288, 13,684	3,042, 13,516	2,469, 20,093
	Bloqueos temporales de SQL Server: tiempo máximo de espera [ms]	2.636, 1.809	928, 858,5	242,929, 938,706
	Compilaciones de SQL Server/s: promedio	20,384, 5,449	No recopilado	76,157, 6,510
	Compilaciones de SQL Server/s: máximo	332,975, 88,992	No recopilado	295,076, 42,999
	Estadísticas de SQL Server: recompilaciones de SQL Server/s: promedio	0,560, 0,081	No recopilado	0,229, 0,125
	Estadísticas de SQL Server: recompilaciones de SQL Server/s: máximo	22,999, 88,492	No recopilado	17,999, 15,5
	Tasa de lectura y escritura (E/S por base de datos): máximo	2,15, 1,25	No recopilado	1,45, 0,364
	Promedio de longitud de la cola de disco (SQL Server)	66,765, 27,314	129,032, 20,665	182,110, 11,816
	Longitud de la cola de disco máxima (SQL Server)	4.201,185, 5.497,980	3.050,015, 762,542	1.833,765, 775,7
	Longitud de cola de disco: escrituras (SQL Server): promedio	58,023, 13,532	114,197, 19,9	175,621, 10,417
	Longitud de cola de disco: escrituras (SQL Server): máximo	1.005,691, 881,892	1.551,437, 761,891	1.018,642, 768,289
	Lecturas de disco/s (SQL Server): promedio	245,945, 94,131	No recopilado	137,435, 154,103
	Lecturas de disco/s (SQL Server): máximo	6.420,412, 6.450,870	No recopilado	3.863,283, 1.494,805
	Escrituras en disco/s (SQL Server): promedio	458,144, 286,884	No recopilado	984,668, 278,175
	Escrituras en disco/s (SQL Server): máximo	2.990,779, 5.164,949	No recopilado	2.666,285, 4.105,897
Servidor de aplicaciones	Promedio de longitud de la cola de disco (servidor de rastreo)	0,052	0,043	0,030
	Longitud de cola de disco: escrituras (servidor de rastreo)	0,029	0,031	0,026
	Lecturas de disco/s (servidor de rastreo)	5,405	No recopilado	0,798
	Escrituras en disco/s (servidor de rastreo)	48,052	No recopilado	102,235
	Promedio de memoria usada (servidor de rastreo)	68%	45%	52%
	Máximo de memoria usada (servidor de rastreo)	76%	47%	59%
Servidor front-end web	Solicitudes de ASP.NET en cola (promedio de todos los servidores front-end web)	0	0	0
	Promedio de memoria usada (servidor front-end web)	no disponible	no disponible	no disponible
	Máximo de memoria usada (servidor front-end web)	no disponible	no disponible	no disponible
Resultados de las pruebas	cantidad de operaciones correctas	3.631.080	1.247.838	200.000
	Número de errores	7.930	304	0
	Velocidad de rastreo del portal (elementos por segundo)	82	148	81
	Velocidad de rastreo del delimitador (elementos por segundo)	1.573	1.580	1.149
	Velocidad de rastreo total (elementos por segundo)	79	136	76

Datos de prueba

En esta sección se proporcionan datos de prueba que ilustran el rendimiento de la granja de servidores bajo carga.

Latencia de consulta

En el siguiente gráfico se muestran los percentiles de latencia de consulta para esta granja de servidores a medida que aumenta la carga de usuarios (recopilados durante la prueba de rendimiento de consulta). Un percentil de consulta del 95% significa que el 95% de las latencias de consulta que se midieron se encontraban por debajo de ese valor.

En este gráfico se puede ver que, con un índice más pequeño, esta granja de servidores puede mantener una latencia de consulta de fracciones de segundo en el percentil 95, incluso a medida que más usuarios simultáneos (22) realicen consultas en esta granja de servidores.

Rendimiento de consulta

En el siguiente gráfico se muestra el rendimiento de consulta para esta granja de servidores a medida que aumenta la carga de usuarios (recopilado durante la prueba de rendimiento de consulta).

Si tiene en cuenta este gráfico y el anterior, podrá ver que, con 33 millones de elementos en el índice, la granja de servidores puede mantener la latencia de fracciones de segundo en el percentil 75 con aproximadamente 30 usuarios simultáneos. Todavía es posible acomodar más carga de usuarios simultáneos, pero la latencia de consulta aumentará más allá de la marca de fracciones de segundo.

Sin embargo, con 46 millones de elementos en el índice, no se puede acomodar más carga de usuarios simultáneos y la latencia de consulta aumentará.

Tasa de rastreo

En el siguiente gráfico se muestra la tasa de rastreo para esta granja de servidores durante la fase de adquisición de índices del ciclo de vida de búsqueda. Los valores representan un rastreo completo, en elementos rastreados por segundo.

La sobrecarga extra implicada para rastrear de manera efectiva un origen de contenido de sitio de SharePoint tiene como resultado una velocidad menor de rastreo global en esta granja de servidores.

Conclusión general

Esta granja de servidores estaba cerca de la capacidad de memoria RAM para los servidores de consultas.

A continuación, se indican los pasos siguientes para mejorar el rendimiento de esta granja de servidores:

• Agregue más RAM a los dos servidores de consultas. Se recomienda suficiente RAM en el servidor de consultas para el 33% de la partición de índice del componente de la consulta activa, además de 3 GB para el sistema operativo y otros procesos.

• Agregue más RAM al servidor de bases de datos que hospeda la base de datos de propiedades. En esta configuración, las tablas de clave tenían aproximadamente 92 GB de tamaño (incluidos los índices), lo que sugiere un requisito de 30 GB de RAM. Sin embargo, el servidor de bases de datos tenía solo 32 GB de RAM para atender a la base de datos de propiedades, la base de datos de administración de búsqueda y las demás bases de datos de SharePoint Server.

• Agregue matrices de almacenamiento para poder segregar bases de datos en el servidor de bases de datos.

• Escale en horizontal para aumentar el rendimiento o reducir la latencia de consulta, o ambas.

Aunque la velocidad de rastreo es alta en esta granja de servidores con dos bases de datos de rastreo y cuatro componentes de rastreo, puede ser un objetivo importante para la granja de servidores tener determinadas partes más actualizadas del índice; es decir, cierto contenido que se debe rastrear con mucha frecuencia. La adición de otra base de datos de rastreo que se dedica a los hosts en el origen de contenido deseado (con reglas de distribución de host) y la asociación de dos componentes de rastreo adicionales con la base de datos permitirían el objetivo de actualización del índice.

Granja de servidores grande

La configuración esperada usa un servidor web, trece servidores de aplicaciones y tres servidores de bases de datos, tal como se indica a continuación:

• Se usa un servidor web para hospedar un centro de búsqueda. Se puede omitir este servidor web si las búsquedas se realizan siempre desde una granja de servidores de contenido mediante un proxy de aplicación de servicio de búsqueda (instalado en la granja de contenido).

• Se usan tres servidores de aplicaciones para la administración y el rastreo. Esto significa lo siguiente:

  • Administración central y el componente de administración de búsqueda se crean en uno de los servidores de aplicaciones.

  • Cada servidor tiene dos componentes de rastreo. Cada componente de rastreo se adjunta a una base de datos de rastreo diferente.

• Los diez servidores de aplicaciones restantes se usan para la consulta. La configuración preferida es tener diez particiones de índice. Cada servidor tiene un componente de consulta principal de una de las particiones de índice, además de un componente de consulta de conmutación por error de una partición de índice diferente.

• Cuatro servidores de bases de datos sirven de apoyo para la granja de servidores. Un servidor se usa para las bases de datos de administración de búsqueda y propiedades. Un segundo servidor se usa para una base de datos de propiedades. Un tercer servidor se usa para dos bases de datos de rastreo. El cuarto servidor se usa para una base de datos de rastreo y las demás bases de datos de SharePoint. Los servidores de bases de datos deben tener un número dedicado de IOPS para cada base de datos de rastreo, propiedades y administración de búsqueda (por ejemplo, use distintas matrices de almacenamiento).

Especificaciones

En esta sección se ofrece información detallada sobre el hardware, el software, la topología y la configuración del entorno de prueba.

Topología

En esta sección se describe la topología del entorno de pruebas.

Hardware

En esta sección se describe el hardware que se usó para realizar las pruebas.

Nota

Debido a que la granja de servidores de prueba estaba ejecutando versiones preliminares de SharePoint Server 2010 y el equipo deseaba evitar posibles problemas, el hardware que se usó para los servidores tenía más capacidad de la que se necesita normalmente.

Servidores web

Servidor web	Servidor front-end web (1)
Procesador	2 procesadores de núcleo cuádruple a 2,33 GHz
RAM	8 GB
Sistema operativo	Windows Server 2008 R2 de 64 bits
Almacenamiento	2 SAS de 148 GB a 15.000 rpm: RAID 1: SO
Número de tarjetas de interfaz de red	2
Velocidad de tarjetas de interfaz de red	1 gigabit
Autenticación	NTLM
Tipo de equilibrador de carga	Ninguno
Versión de software	SharePoint Server 2010 (versión preliminar)
Servicios que se ejecutan localmente	Todos los servicios

Servidores de aplicaciones

Hay trece servidores de aplicaciones en la granja de servidores. Se usan diez servidores para atender consultas y tres servidores para el rastreo.

Servidor (recuento)	Consulta (10)	Rastreo (2), rastreo y administración (1)
Procesador	2 procesadores de núcleo cuádruple a 2,5 GHz	2 procesadores de núcleo cuádruple a 2,5 GHz
RAM	32 GB	32 GB
Sistema operativo	Windows Server 2008 R2 de 64 bits	Windows Server 2008 R2 de 64 bits
Almacenamiento	2 SAS de 148 GB a 15.000 rpm: RAID 1: SO 4 SAS de 300 GB a 15.000 rpm: RAID 10: Datos	2 SAS de 148 GB a 15.000 rpm: RAID 1: SO/Datos
Número de tarjetas de interfaz de red	2	2
Velocidad de tarjetas de interfaz de red	1 gigabit	1 gigabit
Autenticación	NTLM	NTLM
Tipo de equilibrador de carga	Ninguno	Ninguno
Versión de software	SharePoint Server 2010 (versión preliminar)	SharePoint Server 2010 (versión preliminar)
Servicios que se ejecutan localmente	Búsqueda de SharePoint Server; Servicio de configuración del sitio y consulta de búsqueda	Búsqueda de SharePoint Server

Servidores de bases de datos

Hay cuatro servidores de bases de datos. El primer servidor contiene las bases de datos de propiedades y administración de búsqueda; el segundo servidor contiene una base de datos de propiedades; el tercero contiene dos bases de datos de rastreo; el cuarto contiene una base de datos de rastreo y una base de datos de SharePoint. Tenga en cuenta que los volúmenes de almacenamiento que se crearon optimizaron el hardware existente disponible para la prueba.

Servidor de bases de datos	Bases de datos de SharePoint, de propiedades y de administración de búsqueda	Bases de datos de rastreo
Procesador	2 procesadores de núcleo cuádruple a 3,2 GHz	4 procesadores de doble núcleo a 2,19 GHz
RAM	32 GB	16 GB
Sistema operativo	Windows Server 2008 R2 de 64 bits	Windows Server 2008 R2 de 64 bits
Almacenamiento	2 SAS de 148 GB a 15.000 rpm: RAID 1: SO 2 SAS de 148 GB a 15.000 rpm: RAID 1: Registro temporal 2 SAS de 450 GB a 15.000 rpm: RAID 1: BD temporal 6 SAS de 450 GB a 15.000 rpm: RAID 10: BD de propiedades 2 SAS de 450 GB a 15.000 rpm: RAID 1: DB de administración de búsqueda y de SharePoint 2 SAS de 450 GB a 15.000 rpm: RAID 1: Registros	2 SAS de 148 GB a 15.000 rpm: RAID 1: SO 2 SAS de 148 GB a 15.000 rpm: RAID 1: Registro temporal 2 SAS de 300 GB a 15.000 rpm: RAID 1: DB temporal 6 SAS de 146 GB a 15.000 rpm: RAID 10: DB de rastreo 1 6 SAS de 146 GB a 15.000 rpm: RAID 10: DB de rastreo 2 2 SAS de 300 GB a 15.000 rpm: RAID 1: Registro de BD de rastreo 1 2 SAS de 300 GB a 15.000 rpm: RAID 1: Registro de BD de rastreo 2
Número de tarjetas de interfaz de red	2	2
Velocidad de tarjetas de interfaz de red	1 gigabit	1 gigabit
Autenticación	NTLM	NTLM
Versión de software	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

Datos de rendimiento de consulta

Las siguientes medidas se tomaron con 103 millones de elementos en el índice. Las columnas ofrecen las medidas que se tomaron durante la prueba específica, y los resultados están en la parte inferior de la tabla. Las medidas tomadas se describen de la siguiente forma:

• Latencia de consulta   Estas medidas se tomaron durante una prueba de latencia de consulta, en la que una herramienta de prueba envió un conjunto de consultas estándar, como un usuario, y después midió la latencia resultante. No hubo rastreos en curso durante la prueba.

• Rendimiento de consulta   Estas medidas se tomaron durante una prueba de rendimiento de consulta, en la que una herramienta de prueba envió un conjunto de consultas estándar a la granja de servidores, como un número creciente de usuarios (hasta 120) y midió el rendimiento y la latencia resultantes. No había rastreos en curso durante la prueba.

	Métrica de cuadro de mandos	Rendimiento de consulta
Métricas de CPU	CPU de SQL Server promedio (servidor de bases de datos de propiedades)	34%
	CPU de servidor front-end web promedio	45%
	CPU de servidor de consultas promedio	20%
Confiabilidad	Frecuencia de errores	0%
	Bloqueos de servidores front-end web	0
	Bloqueos de servidores de aplicaciones	0
SQL Server (servidor de bases de datos de propiedades)	Frecuencia de aciertos de caché (SQL Server)	100%
	Bloqueos de SQL Server: tiempo promedio de espera (ms)	0
	Bloqueos de SQL Server: tiempo de espera de bloqueos (ms)	0
	Bloqueos de SQL Server: interbloqueos por segundo	0
	Bloqueos temporales de SQL Server: tiempo promedio de espera (ms)	1,401
	Compilaciones de SQL Server/s	73,349
	Estadísticas de SQL Server: recompilaciones de SQL Server/s	0,006
	Tasa de lectura y escritura (E/S por base de datos)	0,81
	Promedio de longitud de la cola de disco (SQL Server)	0,037
	Longitud de cola de disco: escrituras (SQL Server)	0,003
	Lecturas de disco/s (SQL Server)	9,88
	Escrituras en disco/s (SQL Server)	354,1
Servidor de aplicaciones	Promedio de longitud de la cola de disco (servidor de consultas)	0,002
	Longitud de cola de disco: escrituras (servidor de consultas)	0,002
	Lecturas de disco/s (servidor de consultas)	0,035
	Escrituras en disco/s (servidor de consultas)	6,575
	Promedio de memoria usada (servidor de consultas)	6,548%
	Máximo de memoria usada (servidor de consultas)	6,601%
Servidor front-end web	Solicitudes de ASP.NET en cola (promedio de todos los servidores front-end web)	0
	Promedio de memoria usada (servidor front-end web)	18,081%
	Máximo de memoria usada (servidor front-end web)	19,983%
Resultados de las pruebas	Cantidad de operaciones correctas	10.925
	Número de errores	0
	Latencia de interfaz de usuario de consultas (percentil 75)	3,431 segundos
	Latencia de interfaz de usuario de consultas (percentil 95)	3,512 segundos
	Rendimiento de consulta	36,42 solicitudes por segundo

Datos de rendimiento del rastreo

Las siguientes medidas se tomaron durante los rastreos completos, secuenciales e iniciales del origen de contenido determinado. El tamaño del contenido se expresa en millones de elementos. Las columnas ofrecen las medidas tomadas durante el rastreo específico y los resultados están en la parte inferior de la tabla.

	Métrica de cuadro de mandos	Contenido de SharePoint (3,5 millones)	Recurso compartido de archivos (1 millón)
Métricas de CPU	CPU de SQL Server promedio (servidor de bases de datos de rastreo, servidor de bases de datos de propiedades)	15,74%, N/D	24%, 6,6%
	CPU de SQL Server máxima (servidor de bases de datos de rastreo, servidor de bases de datos de propiedades)	100%, N/D%	100%, 45%
	CPU de indizador promedio	44%	49%
Confiabilidad	Frecuencia de errores	0,0%	0,00%
	Bloqueos de servidores front-end web	0	0
	Bloqueos de servidores de aplicaciones	0	0
SQL Server (servidor de bases de datos de rastreo, servidor de bases de datos de propiedades)	Frecuencia de aciertos de caché (SQL Server)	99,8%, N/D%	99,797%, 99,49%
	Bloqueos de SQL Server: tiempo promedio de espera [ms]	734,916, N/D	1.165, 5,866
	Bloqueos de SQL Server: tiempo máximo de espera [ms]	15.335, N/D	28.683, 210,5
	Bloqueos de SQL Server: tiempo promedio de espera de bloqueos [ms]	108,98, N/D	847,72, 5,325
	Bloqueos de SQL Server: tiempo máximo de espera de bloqueos [ms]	17.236,96, N/D	124.353, 12.920
	Bloqueos de SQL Server: interbloqueos por segundo	0, N/D	0,012, 0
	Bloqueos temporales de SQL Server: tiempo promedio de espera [ms]	1,4, N/D	2,233, 40,6
	Bloqueos temporales de SQL Server: tiempo máximo de espera [ms]	1.606, N/D	917,8, 1.895
	Compilaciones de SQL Server/s: promedio	24,28, N/D	72,7, 11,39
	Compilaciones de SQL Server/s: máximo	416, N/D	460, 76,62
	Estadísticas de SQL Server: recompilaciones de SQL Server/s: promedio	0,560, N/D	0,295, 0,099
	Estadísticas de SQL Server: recompilaciones de SQL Server/s: máximo	0,24, N/D	17,50, 17,393
	Tasa de lectura y escritura (E/S por base de datos): máximo	20,3, N/D	1,18/0,214
	Promedio de longitud de la cola de disco (SQL Server)	90,113, N/D	138,64, 27,478
	Longitud de la cola de disco máxima (SQL Server)	3.179, N/D	2.783,543, 847,574
	Longitud de cola de disco: escrituras (SQL Server): promedio	86,93, N/D	130.853, 26,086
	Longitud de cola de disco: escrituras (SQL Server): máximo	1.882, N/D	2.781,197, 884,801
	Lecturas de disco/s (SQL Server): promedio	99, N/D	147,462, 159,159
	Lecturas de disco/s (SQL Server): máximo	3.772, N/D	2.403,336, 896,462
	Escrituras en disco/s (SQL Server): promedio	373, N/D	475,886, 539,497
	Escrituras en disco/s (SQL Server): máximo	18.522, N/D	2.031,888, 4.174,271
Servidor de aplicaciones	Promedio de longitud de la cola de disco (servidor de rastreo)	0,075	0,063
	Longitud de cola de disco: escribe (servidor de rastreo)	0,046	0,053
	Lecturas de disco/s (servidor de rastreo)	1,958	1,693
	Escrituras en disco/s (servidor de rastreo)	62,33	101,093
	Promedio de memoria usada (servidor de rastreo)	59%	56,38%
	Máximo de memoria usada (servidor de rastreo)	70%	58,93%
Servidor front-end web	Solicitudes de ASP.NET en cola (promedio de todos los servidores front-end web)	No disponible	No disponible
	Promedio de memoria usada (servidor front-end web)	No disponible	No disponible
	Máximo de memoria usada (servidor front-end web)	No disponible	No disponible
Resultados de las pruebas	Cantidad de operaciones correctas	1.909.739	1.247.838
	Número de errores	9.361	331
	Velocidad de rastreo del portal (elementos por segundo)	70,3	131,44
	Velocidad de rastreo del delimitador (elementos por segundo)	764	525,84
	Velocidad de rastreo total (elementos por segundo)	64	105

Recomendaciones y solución de problemas

En las secciones siguientes se proporcionan recomendaciones acerca de cómo determinar el hardware, la topología y la configuración que necesita para implementar entornos similares a estos escenarios y cómo optimizar el entorno para las características de rendimiento y capacidad adecuadas.

Recomendaciones

En esta sección se describen las acciones específicas que se pueden realizar para optimizar el entorno para las características de rendimiento y capacidad adecuadas.

Recomendaciones de hardware

Para obtener información específica acerca de los requisitos mínimos y recomendados del sistema en general, vea Requisitos de hardware y software (SharePoint Server 2010). Tenga en cuenta que los requisitos para los servidores que se usaron para la búsqueda reemplazan a los requisitos generales del sistema. Use las siguientes instrucciones recomendadas para IOPS, procesador y RAM a fin de satisfacer los objetivos de rendimiento.

Tamaño de la búsqueda

En esta sección se explica el sistema de búsqueda, incluidos los requisitos de tamaño y las instrucciones, por componente.

SharePoint Server 2010 se puede implementar y configurar de varias maneras. Como resultado, no hay una forma sencilla para calcular cuántos usuarios o elementos pueden ser admitidos por un número determinado de servidores. Por lo tanto, asegúrese de que realiza pruebas en su propio entorno antes de implementar SharePoint Server 2010 en un entorno de producción.

Sistema de consulta de búsqueda

En esta sección se muestran los componentes del sistema de consulta de búsqueda para una aplicación de servicio de búsqueda dada. Los requisitos de tamaño para cada componente se enumeran en la tabla Detalles de escalado después del siguiente diagrama.

Descripción de los objetos

En la siguiente lista se definen los objetos del sistema de consulta de búsqueda que se encuentran en el diagrama anterior:

• Proxy de búsqueda   Se trata del proxy de aplicación de servicio de búsqueda que está instalado en cualquier granja de servidores que usa la búsqueda desde esta aplicación de servicio de búsqueda. Se ejecuta en el contexto de las aplicaciones web que se asocian con el proxy de aplicación de servicio de búsqueda.

• Servicio de configuración del sitio y consulta de búsqueda   Se le conoce también como el procesador de consultas. Al recibir la consulta de una conexión de proxy de aplicación de servicio de búsqueda, un procesador de consultas hace lo siguiente:

  • Envía la consulta a un componente de consulta activo para cada partición de índice (o a la base de datos de propiedades, o ambos, según la consulta).

  • Recupera las opciones más probables y quita los duplicados para obtener el conjunto de resultados.

  • Hace recortes de seguridad en los resultados según los descriptores de seguridad en la base de datos de administración de búsqueda.

  • Recupera los metadatos del conjunto de resultados finales desde la base de datos de propiedades.

  • Vuelve a enviar los resultados de la consulta al proxy.

• Partición de índice   Se trata de un grupo lógico de componentes de consulta, que representa un subconjunto del índice de texto completo. La suma de las particiones de índice conforma el índice de texto completo. Sin embargo, tenga en cuenta que los componentes de consulta contienen el subconjunto real del índice. Una partición de índice se asocia con una base de datos de propiedades.

• Componente de consulta de búsqueda   Un componente de consulta contiene la totalidad o parte del índice de texto completo. Cuando se consulta mediante un procesador de consultas, el componente de la consulta determina los mejores resultados de su índice y devuelve esos elementos. Un componente de consulta puede crearse como cualquiera de los siguientes:

  • Activo, lo que significa que responderá a las consultas de manera predeterminada. La adición de varios componentes de consulta activos para la misma partición de índice aumentará el rendimiento.

  • Conmutación por error, lo que significa que solo responderá a las consultas si se produjo un error en todos los componentes activos para la misma partición de índice.

• Base de datos de administración de búsqueda   Creada al mismo tiempo que la aplicación de servicio de búsqueda, la base de datos de administración de búsqueda contiene los datos de toda la aplicación de servicio de búsqueda utilizados para consultas como las opciones más probables y los descriptores de seguridad, además de la configuración de la aplicación que se usa para la administración.

• Base de datos de propiedades   Una base de datos de propiedades contiene los metadatos (título, autor, campos relacionados) de los elementos en el índice. La base de datos de propiedades se usa para consultas basadas en propiedades, además de para recuperar los metadatos necesarios a fin de mostrar los resultados finales. Si existen varias particiones de índice, las particiones de índice se pueden asignar a distintas bases de datos de propiedades.

Detalles de escalado

Objeto	Consideraciones de escala	RAM	IOPS (lectura y escritura)
Proxy de búsqueda	Se escala con los servidores front-end web a los que se asocia.	No disponible	No disponible
Servicio de configuración del sitio y consulta de búsqueda	Este servicio, que está instalado en la página Servicios del servidor en Administración central, se debe iniciar en cada servidor con un componente de consulta. Se puede mover a un servidor independiente (o dos, para alcanzar una alta disponibilidad), a fin de evitar el uso de memoria RAM en los servidores que contienen los componentes de consulta. Además, si se usa un optimizador de seguridad personalizado, puede afectar a los recursos de la memoria RAM y la CPU.	Esto usa memoria RAM (caché de proceso) para almacenar en caché los descriptores de seguridad para el índice.	No disponible
Partición de índice	El aumento del número de particiones de índice reduce el número de elementos en la partición de índice, y esto reduce la memoria RAM y el espacio en disco que se necesitan en el servidor de consultas que hospeda el componente de consulta asignado a la partición de índice.	No disponible	No disponible
Componente de consulta	Cada componente de consulta activo en un servidor consume memoria cuando está atendiendo consultas. Cada componente de consulta activo se crea o se modifica como parte de la topología de una aplicación de servicio de búsqueda. Tanto los componentes activos como los de conmutación por error consumen E/S cuando se lleva a cabo el rastreo. Los servidores pueden dedicarse a los componentes de consulta (por ejemplo, dos activos y dos de conmutación por error en el mismo servidor), siempre que se hayan cumplido los requisitos de RAM y de E/S. Cuando sea posible, dedique al menos dos núcleos de CPU por componente activo por servidor y al menos un núcleo de CPU por componente de conmutación por error por servidor.	Para cada componente de consulta activo en un servidor de aplicaciones, 33% de su índice debe estar en la memoria RAM (caché del sistema operativo).	2.000 necesarios por cada par (activo/conmutación por error) de componentes de consulta en un servidor determinado. El componente de consulta necesita E/S para: Cargar el índice en la memoria RAM para las consultas Escribir fragmentos de índice que se reciben desde cada componente de rastreo Combinar fragmentos de índice en su índice, como durante una combinación maestra
Base de datos de administración de búsqueda	Para cada consulta, las opciones más probables y los descriptores de seguridad se cargan desde la base de datos de administración de búsqueda. Asegúrese de que el servidor de bases de datos tiene suficiente memoria RAM para proporcionar esto desde la memoria caché. Cuando sea posible, evite colocarla en un servidor con una base de datos de rastreo, porque la base de datos de rastreo tiende a restablecer la memoria caché de su servidor de bases de datos.	Asegúrese de que el servidor de bases de datos tiene suficiente memoria RAM para mantener la tabla crítica (MSSSecurityDescriptors) en la memoria RAM.	700
Base de datos de propiedades	Para cada consulta, se recuperan metadatos de la base de datos de propiedades para los resultados del documento, de modo que es posible agregar memoria RAM al servidor de bases de datos para mejorar el rendimiento. Si existen varias particiones de índice, puede crear particiones de la base de datos de propiedades y moverla a un servidor de bases de datos distinto para reducir los requisitos de RAM y E/S.	Asegúrese de que el servidor de bases de datos tiene suficiente memoria RAM para mantener un 33% de las tablas críticas (MSSDocSDIDs + MSSDocProps + MSSDocresults) en la memoria caché.	2.000 30% lectura, 70% escritura

Sistema de rastreo de búsqueda

En esta sección se muestran los componentes del sistema de rastreo de búsqueda. Los requisitos de tamaño de cada componente aparecen en la tabla que sigue al diagrama.

Descripción de los objetos

En esta sección se definen los objetos del sistema de rastreo de búsqueda del diagrama anterior:

• Componente de administración   Un componente de administración se usa cuando se inicia un rastreo, además de cuando se realiza una tarea de administración en el sistema de rastreo.

• Componente de rastreo   Un componente de rastreo procesa rastreos, propaga los archivos de fragmento de índice resultantes a los componentes de consulta y agrega información sobre la ubicación y programación de rastreo de los orígenes de contenido en la base de datos de rastreo asociada.

• Base de datos de administración de búsqueda   La base de datos de administración de búsqueda, que se crea al mismo tiempo que la aplicación de servicio de búsqueda, almacena los descriptores de seguridad que se detectan durante el rastreo, además de la configuración de la aplicación que se usa para la administración.

• Base de datos de rastreo   Una base de datos de rastreo contiene datos relacionados con la ubicación de los orígenes de contenido, programaciones de rastreo y otra información que es específica de las operaciones de rastreo. Se pueden dedicar a hosts específicos mediante la creación de reglas de distribución de host. Una base de datos de rastreo solo almacena datos. El componente de rastreo que está asociado con la base de datos de rastreo dada realiza el rastreo.

• Sistema de consulta de búsqueda

Detalles de escalado

Objeto	Consideraciones de escala	RAM	IOPS (opcionalmente, % lectura y escritura)
Componente de administración	El único componente de administración no es escalable. De manera predeterminada, se encuentra en un servidor que hospeda un componente de rastreo (y Administración central, en granjas de servidores más pequeñas).	Mínima	Mínimo
Componente de rastreo	Los componentes de rastreo usan intensamente el ancho de banda de la CPU. En condiciones óptimas, un componente de rastreo determinado puede usar cuatro núcleos de CPU. La memoria RAM no es tan importante. En entornos más grandes, dedicar servidores para que hospeden componentes de rastreo minimiza el efecto del rastreador sobre otros componentes (especialmente con los componentes de rastreo asociados con distintas bases de datos de rastreo, si se desea la redundancia).	Moderada. Tenga en cuenta que, cuando se rastrean documentos de Asia del Este, los requisitos de RAM aumentarán debido a los separadores de palabras.	300-400
Base de datos de administración de búsqueda	Vea Sistema de consulta de búsqueda más arriba. Cuando sea posible, evite ubicarla en un servidor con una base de datos de rastreo, porque la base de datos de rastreo tiende a restablecer la memoria caché de su servidor de bases de datos.	Vea Sistema de consulta de búsqueda más arriba.	700
Base de datos de rastreo	Las bases de datos de rastreo usan intensamente el ancho de banda de E/S. La memoria RAM no es tan importante. Una base de datos de rastreo necesita 3.500 IOPS para rastrear actividades; consumirá hasta 6.000 IOPS, según el ancho de banda disponible.	Moderada	3.500 – 7.000 73% lectura, 27% escritura

Calcular el tamaño de almacenamiento

Calcule los factores siguientes para ayudar a estimar los requisitos de almacenamiento. Los factores de tamaño se basan en un sistema interno previo a la implementación con un índice que contiene principalmente contenido de SharePoint (el tamaño de las bases de datos de contenido es 13,3 terabytes). En general, la búsqueda de SharePoint requería aproximadamente el 20% del espacio en disco de la base de datos de contenido. Como se indicó anteriormente, asegúrese de realizar pruebas en su propio entorno antes de implementar SharePoint Server 2010 en un entorno de producción.

Advertencias:

• El corpus que se usó para derivar estos números fue principalmente contenido de SharePoint (en inglés), por lo que si el contenido es distinto (por ejemplo, consta principalmente de recursos compartidos de archivos o sitios HTTP que no son de SharePoint), se deberá permitir mayor variación.

• Incluso si el contenido es principalmente contenido de SharePoint, se pueden variar los coeficientes en las siguientes circunstancias:

  • Si dispone de repositorios para documentos grandes, los coeficientes serán mucho mayores.

  • Si el contenido está formado principalmente por imágenes, es posible que pueda reducir los coeficientes.

  • El contenido en un idioma diferente probablemente afecte a los coeficientes.

1. Cálculo del factor de tamaño de la base de datos de contenido (ContentDBSum)

Determine la suma de las bases de datos de contenido de SharePoint que se van a rastrear. Se trata del valor ContentDBSum que se usará como la correlación en los siguientes cálculos de almacenamiento.

2. Cálculo de los tamaños relacionados con el índice (TotalIndexSize y QueryComponentIndexSize)

Determine el tamaño del índice total (que se encuentra en los componentes de consulta y se usa para consultas de texto completo):

Multiplique ContentDBSum por 0,035. Se trata del valor TotalIndexSize antes de crear particiones y reservar espacio para volver a crear particiones y combinaciones.

A continuación, determine el número de particiones de índice que tendrá en función del escenario. Una pauta general es que una partición de índice debe tener entre 5 y 10 millones de elementos. Cuando haya determinado el número de particiones de índice, podrá calcular el tamaño de almacenamiento del componente de consulta.

• Divida TotalIndexSize entre (número de particiones de índice). Se trata del valor QueryComponentIndexSize. Se usa para calcular los tamaños siguientes:

  • Para la memoria RAM, multiplique QueryComponentIndexSize por 0,33. Se trata del mínimo de RAM necesario para este componente de consulta, si está activo.

    • Si el componente es un componente de conmutación por error, no requiere la memoria RAM hasta que se vuelve activo.

    • Para un servidor determinado, tener varios componentes de consulta activos en el mismo servidor significa que es necesario sumar la memoria RAM de cada componente de consulta activo para determinar las necesidades de memoria RAM del servidor.

  • Para el almacenamiento en disco, use QueryComponentIndexSize de las siguientes maneras para estimar los requisitos de disco, en función de si volverá a crear particiones de índice (es decir, espera que el índice crezca en más de 10 millones por límite de partición):

    • Multiplique QueryComponentIndexSize por 3 para calcular el almacenamiento en disco de un solo componente de consulta a fin de dejar espacio para la combinación de índices.

    • Multiplique QueryComponentIndexSize por 4 para calcular el almacenamiento en disco de un solo componente de consulta a fin de dejar espacio para volver a crear particiones de índice.

Para un servidor determinado, tener varios componentes de consulta en el mismo servidor significa que es necesario organizar el almacenamiento de cada uno de los componentes de consulta dados los requisitos de IOPS en la sección "Detalles de escalado" de la sección "Sistema de consulta de búsqueda", anteriormente en este artículo.

3. Cálculo de los tamaños de las bases de datos de propiedades

Determine el tamaño de las bases de datos de propiedades de la siguiente manera:

• Multiplique ContentDBSum por 0,015. Se trata del valor TotalPropertyDBSize antes de crear particiones.

• Multiplique ContentDBSum por 0,0031. Se trata del valor TotalPropertyDBLogSize antes de crear particiones. Se da por sentado que usa el modelo de recuperación simple para bases de datos de SQL Server.

• Multiplique ContentDBSum por 0,00034. Se trata de la base de datos de propiedades TempDBSize. Debido a que se recomienda tener 33% de las tablas de clave en la base de datos de propiedades en la memoria RAM, el uso de la base de datos temporal no es pesado.

A continuación, determine el número de bases de datos de propiedades que tendrá, en función del escenario. Una pauta general es que una base de datos de propiedades debe contener hasta 50 millones de elementos, siempre que no haya problemas de rendimiento de consulta y que tenga un número limitado de propiedades administradas (la configuración estándar).

• Divida TotalPropertyDBSize entre (número de bases de datos de propiedades). Se trata del valor PropertyDatabaseSize.

• Divida TotalPropertyDBLogSize entre (número de bases de datos de propiedades). Se trata del valor PropertyDatabaseLogSize.

• Para la memoria RAM, multiplique PropertyDatabaseSize por 0,33. Se trata de la cantidad mínima de RAM recomendada para esta base de datos de propiedades.

Para un servidor de bases de datos determinado, tener varias bases de datos de propiedades en el mismo servidor significa que es necesario organizar el almacenamiento y la memoria RAM de cada una de las bases de datos de propiedades dados los requisitos de IOPS y RAM en la sección "Detalles de escalado" de la sección "Sistema de consulta de búsqueda", anteriormente en este artículo.

4. Cálculo de los tamaños de las bases de datos de rastreo

A continuación, determine el tamaño necesario para la base de datos de rastreo de la siguiente manera:

• Multiplique ContentDBSum por 0,046. Se trata del valor TotalCrawlDBSize antes de crear particiones.

• Multiplique ContentDBSum por 0,011. Se trata del valor TotalCrawlDBLogSize antes de crear particiones. Se da por sentado que usa el modelo de recuperación simple para bases de datos de SQL Server.

• Multiplique ContentDBSum por 0,0011. Se trata de la base de datos de rastreo TempDBSize. Debido a que el sistema de rastreo de búsqueda afecta al rendimiento de la base de datos temporal, no se recomienda ubicar otras bases de datos en servidores que hospedan la base de datos de rastreo o bases de datos que se verían afectadas por este uso.

A continuación, determine el número de bases de datos de rastreo que tendrá, en función del escenario. Una pauta general es que una base de datos de rastreo debe contener hasta 25 millones de elementos, siempre que no haya problemas de rendimiento de rastreo.

• Divida TotalCrawlDBSize entre (número de bases de datos de rastreo). Se trata del valor CrawlDatabaseSize.

• Divida TotalCrawlDBLogSize entre (número de bases de datos de rastreo). Se trata del valor CrawlDatabaseLogSize.

Para un servidor de bases de datos determinado, tener varias bases de datos de rastreo en el mismo servidor significa que es necesario organizar el almacenamiento de cada una de las bases de datos de rastreo dados los requisitos de IOPS en la sección "Detalles de escalado" de la sección "Sistema de rastreo de búsqueda", anteriormente en este artículo. Para la memoria RAM, se recomienda al menos 16 GB en los servidores de bases de datos que se dedican a las bases de datos de rastreo.

5. Cálculo del tamaño de la base de datos de administración de búsqueda

Determine el tamaño de la base de datos de administración de búsqueda (dando por supuesto que la autenticación es Windows) de la siguiente manera:

• Multiplique número de elementos en el índice (en millones) por 0,3. Se trata del valor SearchAdminDBSize.

• Para la memoria RAM, multiplique SearchAdminDBSize por 0,33. Se trata de la cantidad mínima de RAM recomendada para esta base de datos de administración de búsqueda.

Para un servidor de bases de datos determinado, tener varias bases de datos en el mismo servidor significa que es necesario organizar el almacenamiento y la memoria RAM de cada una de las bases de datos dados los requisitos de IOPS y RAM en la sección "Detalles de escalado" de la sección "Sistema de consulta de búsqueda", anteriormente en este artículo.

Opcional: cálculo del tamaño de la copia de seguridad

Para determinar el espacio en disco necesario para crear una copia de seguridad de una aplicación de servicio de búsqueda, realice el siguiente cálculo:

• TotalCrawlDBSize + TotalPropertyDBSize + TotalIndexSize + SearchAdminDBSize = el tamaño básico de la copia de seguridad.

Este tamaño básico de la copia de seguridad es un punto de partida. También se verá afectado por lo siguiente:

• El tamaño de índice adicional que se incluye en TotalIndexSize para los rastreos que se hayan producido desde la última combinación maestra.

• Crecimiento en el tiempo debido a elementos, consultas y descriptores de seguridad adicionales.

Por lo demás, tal vez resulte conveniente conservar varias copias de seguridad de momentos diferentes, además de reservar espacio para la siguiente copia de seguridad.

Ejercicio de tamaño

Con los factores de tamaño mencionados anteriormente, el siguiente es un ejercicio de tamaño para una granja de 100 millones de elementos que atenderá consultas principalmente para contenido de SharePoint. Mediante el escenario de granja de servidores grande, se asumiría lo siguiente:

• Se necesitan diez particiones de índice lógicas para dar cabida a los 100 millones de elementos.

• Para atender consultas, se necesitan diez componentes de consulta activos, uno por cada partición de índice.

• La redundancia de consultas es importante, por lo que tiene diez componentes de consulta de conmutación por error, uno por cada partición de índice (que se encuentran en un servidor diferente al del componente activo).

Para determinar las necesidades de almacenamiento y memoria RAM, lleve a cabo los pasos siguientes:

1. En una granja de servidores de contenido de SharePoint con varias bases de datos de contenido, junte las bases de datos de contenido que desee rastrear para obtener 20 terabytes.

2. Mediante el coeficiente de índice anterior, multiplique 20 terabytes por 0,035 (coeficiente de índice) para obtener 716,8 GB. Se trata del valor TotalIndexSize. Si solo tenía una partición, se trataría del tamaño del índice, sin actividad.

3. Divida TotalIndexSize entre el número de particiones: 716,8 GB / 71,68 GB. Se trata del tamaño de índice que se necesita para cada componente de consulta (QueryComponentIndexSize), con una partición de índice. El tamaño es el mismo para los componentes de consulta activos o de conmutación por error.

4. Multiplique TotalIndexSize por 4 si planea volver a crear particiones; de lo contrario, multiplique por 3 para admitir combinaciones maestras. 71,68 GB * 4 = 286,72 GB. Debe tener 286,72 GB disponibles en el disco del servidor de consultas para admitir un componente de consulta. Si tiene dos componentes de consulta en el mismo servidor de aplicaciones (como en la topología de componentes activos y de conmutación por error que se recomendó en el escenario de la granja de servidores grande), tendría un diseño de unidad de disco como se indica a continuación:

   1. Unidad de sistema operativo (tamaño estándar).

   2. Sistema de almacenamiento extra 1: Component1_Share de consulta (tamaño = al menos 300 GB), se usa para el componente de consulta activo desde la partición de índice 1.

   3. Sistema de almacenamiento extra 2: Component2_Share de consulta (tamaño = al menos 300 GB), se usa para el componente de consulta (reflejado) de conmutación por error desde la partición de índice 2.

Nota

En este servidor de aplicaciones, con un componente de consulta activo, tal vez desee un mínimo de 71,68 GB * 0,33 = 23,65 GB de RAM + 3 GB de RAM para el sistema operativo (se usan 32 GB), para almacenar en caché la mayor parte de las consultas.

Límites del software

En la tabla siguiente se proporcionan los límites del software que se imponen para lograr una experiencia de búsqueda aceptable.

Objeto	Límite	Notas adicionales
Aplicación de servicio de búsqueda de SharePoint	Máximo recomendado de 20 por granja de servidores. Máximo absoluto de un total de 256 aplicaciones de servicio.	Puede implementar varias aplicaciones de servicio de búsqueda en la misma granja de servidores, ya que puede asignar las bases de datos y los componentes de búsqueda a servidores independientes.
Documentos indizados	Máximo general recomendado de 10 millones de elementos por partición de índice y 100 millones de elementos por aplicación de servicio de búsqueda.	La búsqueda de SharePoint admite particiones de índice, cada una de las cuales contiene un subconjunto de todo el índice de búsqueda. El máximo recomendado es de 10 millones de elementos para una partición determinada. El número máximo total de elementos recomendado, incluidas personas, elementos de lista, documentos y páginas web, es de 100 millones.
Particiones de índice	Máximo recomendado de 20 por aplicación de servicio de búsqueda.	Esta partición de índice es un subconjunto lógico del índice de la aplicación de servicio de búsqueda. El límite recomendado es de 20. El aumento del número de particiones de índice reduce el número de elementos en la partición de índice, lo que reduce la memoria RAM y el espacio en disco que se necesitan en el servidor de consultas que hospeda el componente de consulta asignado a la partición de índice. Sin embargo, esto puede afectar a la relevancia porque el número de elementos de la partición de índice disminuye. El límite estricto de particiones de índice es de 128.
Base de datos de propiedades	El límite recomendado es de 10 por aplicación de servicio de búsqueda.	La base de datos de propiedades almacena los metadatos de los elementos de cada partición de índice asociada que se asocia con ella. Una partición de índice puede estar asociada con un solo almacén de propiedades. El límite recomendado es de 10 por aplicación de servicio de búsqueda, con un límite estricto de 255 (el mismo que las particiones de índice).
Bases de datos de rastreo	El límite es de 32 bases de datos de rastreo por aplicación.	La base de datos de rastreo almacena los datos de rastreo (incluidos el tiempo y el estado) acerca de todos los elementos rastreados. El límite recomendado es de 25 millones de elementos por base de datos de rastreo, o bien de cuatro bases de datos en total por aplicación de servicio de búsqueda.
Componentes de rastreo	El límite recomendado por aplicación es de 16 componentes de rastreo en total, a razón de dos por base de datos de rastreo, y dos por servidor, siempre que el servidor tenga al menos ocho procesadores (núcleos).	El número total de componentes de rastreo por servidor debe ser inferior a 128/(total de componentes de consulta) para minimizar la degradación de E/S de propagación. Aunque se exceda el límite recomendado, es posible que no aumente el rendimiento del rastreo. De hecho, el rendimiento de rastreo podría reducirse en función de los recursos disponibles en el servidor de rastreo, la base de datos y el host de contenido.
Componentes de consulta	El límite recomendado por aplicación es de 128, a razón de 64/(total de componentes de rastreo) por servidor.	El número total de componentes de consulta está limitado por la capacidad de los componentes de rastreo de copiar archivos. El número máximo de componentes de consulta por servidor está limitado por la capacidad de los componentes de consulta de absorber archivos propagados desde componentes de rastreo.
Rastreos simultáneos	El límite recomendado es de 20 rastreos por aplicación de servicio de búsqueda.	Este es el número de rastreos que se pueden realizar al mismo tiempo. Los rastreos son tareas de búsqueda extremadamente costosas que pueden afectar a la carga de la base de datos, además de la carga de otras aplicaciones. Superar 20 rastreos simultáneos puede degradar la tasa de rastreo global.
Orígenes de contenido	El límite recomendado es de 50 orígenes de contenido por aplicación de servicio de búsqueda.	El límite recomendado puede excederse hasta el límite estricto de 500 por aplicación de servicio de búsqueda. No obstante, deben usarse menos direcciones de inicio y debe seguirse el límite de rastreo simultáneo.
Direcciones de inicio	El límite recomendado es de 100 direcciones de inicio por origen de contenido.	El límite recomendado puede excederse hasta el límite estricto de 500 por origen de contenido. Sin embargo, se deben usar menos orígenes de contenido. Cuando hay muchas direcciones de inicio es mejor colocarlas en una página HTML como vínculos y, a continuación, hacer que el rastreador HTTP rastree la página, siguiendo los vínculos.
Reglas de rastreo	El límite recomendado es de 100 por aplicación de servicio de búsqueda.	La recomendación puede excederse, pero se degradará la presentación de las reglas de rastreo en la administración de búsqueda.
Registros de rastreo	El límite recomendado es de 100 millones por aplicación.	Este es el número de entradas de registro individuales en el registro de rastreo. Seguirá el límite de documentos indizados.
Propiedades de metadatos reconocidas por elemento	El límite estricto es de 10.000.	Este es el número de propiedades de metadatos que, cuando se rastrea un elemento, se puede determinar (y potencialmente asignar y usar para consultas).
Propiedades rastreadas	500.000 por aplicación de servicio de búsqueda.	Se trata de las propiedades detectadas durante un rastreo.
Propiedades administradas	100.000 por aplicación de servicio de búsqueda.	Estas son las propiedades que usa el sistema de búsqueda en las consultas. Las propiedades rastreadas se asignan a propiedades administradas. Se recomienda un máximo de 100 asignaciones por propiedad administrada. Si se excede este límite, se puede reducir la velocidad de rastreo y el rendimiento de las consultas.
Ámbitos	El límite recomendado es de 200 por sitio.	Este es un límite recomendado por sitio. Si se excede este límite, se puede reducir la eficiencia del rastreo, además de afectar a la latencia del explorador de usuario final si se agregan los ámbitos al grupo de presentación. Además, la presentación de los ámbitos en la administración de búsqueda se degrada a medida que el número de ámbitos excede el límite recomendado.
Grupos de presentación	25 por sitio	Se usan para la presentación agrupada de ámbitos a través de la interfaz de usuario. Si excede este límite, se iniciará la degradación de la experiencia de ámbito de administración de búsqueda.
Reglas de ámbito	El límite recomendado es de 100 reglas de ámbito por ámbito y un total de 600 por aplicación de servicio de búsqueda.	Si se excede este límite, se degradará la actualización y se retrasarán los resultados potenciales de las consultas del ámbito.
Palabras clave	El límite recomendado es de 200 por colección de sitios.	El límite recomendado puede excederse hasta el límite máximo (impuesto por ASP.NET) de 5.000 por colección de sitios, con cinco opciones más probables por palabra clave. La presentación de palabras clave en la interfaz de usuario de administración del sitio se degradará. El límite impuesto por ASP.NET puede modificarse editando los archivos Web.config y Client.config (MaxItemsInObjectGraph).
Páginas relevantes	El límite recomendado es de una página relevante de nivel superior y el menor número posible de páginas de segundo y tercer nivel, al tiempo que se logra la relevancia deseada.	El límite estricto es de 200 por nivel de relevancia por aplicación de servicio de búsqueda, pero aunque se agreguen páginas, es posible que no se logre la relevancia deseada. Agregue el sitio clave al primer nivel de relevancia. Agregue más sitios clave como segundo o tercer nivel de relevancia, de uno en uno, evaluando la relevancia después de cada adición para asegurarse de que se ha logrado el efecto de relevancia deseado.
Alertas	El límite recomendado es de 1.000.000 por aplicación de servicio de búsqueda.	Este es el límite probado.
Eliminación de resultados	100 direcciones URL en una sola operación	Este es el número máximo recomendado de direcciones URL que deberían quitarse del sistema en una misma operación.

Optimizaciones

En las siguientes secciones se explican los métodos para mejorar el rendimiento de la granja de servidores.

Muchos factores pueden afectar al rendimiento. Estos factores incluyen el número de usuarios; el tipo, la complejidad y la frecuencia de las operaciones de usuario; el número de devoluciones (postbacks) en una operación; y el rendimiento de las conexiones de datos. Cada uno de estos factores puede tener un efecto importante sobre el rendimiento de la granja de servidores. Debe considerar cuidadosamente cada uno de estos factores al planear la implementación.

La capacidad y el rendimiento de un sistema de búsqueda son sumamente dependientes de su topología. Puede escalar en vertical aumentando la capacidad de los equipos de servidor existentes o escalar en horizontal agregando servidores a la topología.

Optimizaciones del sistema de consulta de búsqueda

Por lo general, las optimizaciones de consulta de búsqueda siguen uno de estos escenarios:

• Los usuarios se están quejando acerca de la latencia de las consultas, por lo que hay que reducirla.

• Se están produciendo muchas más solicitudes de búsqueda de las planeadas y el rendimiento ha empezado a disminuir, por lo que hay que aumentar el rendimiento de consulta.

El escalado horizontal o vertical del subsistema de consultas siempre implica la creación de más componentes de consulta. Si tiene exceso de capacidad (RAM, CPU y E/S) en un servidor de consultas existente, puede optar por escalar en vertical mediante la creación de más componentes de consulta en ese servidor, incrementando la memoria RAM, la CPU o E/S si alcanza un cuello de botella. De lo contrario, puede optar por crear más componentes de consulta (o mover los componentes existentes) en un nuevo servidor para escalar en horizontal.

En la siguiente sección se muestran varias formas de agregar recursos de consulta al sistema de consulta de búsqueda.

Reducción de la latencia de las consultas

Adición de componentes de consulta para reducir la latencia

En el siguiente gráfico se ilustra el efecto de agregar componentes de consulta activos en diferentes servidores sin cambiar el tamaño del índice.

Agregue más componentes de consulta activos para conservar la latencia de consultas de fracciones de segundo a medida que aumenta la carga de usuarios en el sistema (que se mide en consultas de usuarios simultáneos).

Adición de procesadores de consultas (servicio de configuración del sitio y consulta) para reducir la latencia

En el siguiente gráfico se ilustra el efecto de agregar servicios de procesador de consultas activas en diferentes servidores sin cambiar ninguna otra parte del sistema de consultas.

Inicie otras instancias activas del servicio de configuración del sitio y consulta en servidores diferentes para conservar la latencia de consultas de fracciones de segundo a medida que aumenta la carga de usuarios en el sistema (que se mide en consultas de usuarios simultáneos).

Escalado horizontal para aumentar el rendimiento de consulta

Adición de componentes de consulta para aumentar el rendimiento de consulta

En el siguiente gráfico se ilustra el efecto de agregar componentes de consulta activos en diferentes servidores sin cambiar el tamaño del índice.

Agregue más componentes de consulta activos para aumentar el rendimiento de consulta a medida que aumenta la carga de usuarios en el sistema (que se mide en consultas de usuarios simultáneos).

Adición de procesadores de consultas (servicio de configuración del sitio y consulta) para aumentar el rendimiento de consulta

En el siguiente gráfico se ilustra el efecto de agregar servicios de procesador de consultas activas en diferentes servidores sin cambiar ninguna otra parte del sistema de consultas.

Conclusión: inicie otras instancias activas del servicio de configuración del sitio y consulta en servidores diferentes para aumentar el rendimiento a medida que aumenta la carga de usuarios en el sistema (que se mide en consultas de usuarios simultáneos).

Optimizaciones del sistema de rastreo de búsqueda

Por lo general, se realizan optimizaciones de rastreo de búsqueda cuando los usuarios se quejan sobre los resultados que debería haber pero no hay, o que hay pero están obsoletos.

Al intentar rastrear la dirección de inicio de origen de contenido dentro de los objetivos de actualización, se puede topar con los siguientes problemas de rendimiento de rastreo:

• La tasa de rastreo es baja debido a los cuellos de botella de IOPS en el subsistema de rastreo de búsqueda.

• La tasa de rastreo es baja debido a la falta de subprocesos de CPU en el subsistema de rastreo de búsqueda.

• La tasa de rastreo es baja debido a la lenta capacidad de respuesta del repositorio.

En cada uno de estos problemas se asume que la tasa de rastreo es baja. Vea Uso de informes de administración de búsquedas (SharePoint Server 2010) (dadas las fases del ciclo de vida del software) para establecer una línea de base para la tasa de rastreo típica del sistema a lo largo del tiempo. Cuando esta línea de base experimenta un retroceso, las siguientes subsecciones mostrarán diversas maneras de afrontar estos problemas de rendimiento de rastreo.

Cuello de botella de IOPS de rastreo

Tras determinar que una base de datos de rastreo o una de propiedades es un cuello de botella, se debe escalar en horizontal o vertical el sistema de rastreo para resolverlo mediante las soluciones adecuadas. La tabla siguiente muestra cómo, al agregar IOPS (otra base de datos de rastreo), se mejora la tasa de rastreo (hasta que la adición de más componentes vuelve a crear un cuello de botella).

Conclusión: compruebe siempre la base de datos de rastreo para asegurarse de que no es el cuello de botella. Si los IOPS de la base de datos de rastreo ya se convirtieron en cuello de botella, la adición de componentes de rastreo o el aumento del número de subprocesos no solucionarán el problema.

Topología (Componente de rastreo/ base de datos de rastreo)	Porcentaje de CPU	RAM: proporción de aciertos de caché del búfer (%)	Latencia de lectura	Latencia de escritura	Velocidad de rastreo (documentos por segundo)
2 / 1 base de datos	19,5	99,6	142 ms	73 ms	50
4 / 2 base de datos	8,502	99,55	45 ms	75 ms	~75
6 / 2 base de datos	22	99,92	55 ms	1050 ms	~75

Cuello de botella de subprocesos de CPU de rastreo

Si tiene un gran número de hosts y no tiene ningún otro cuello de botella de rastreo, deberá escalar en horizontal o en vertical el sistema de rastreo mediante las soluciones adecuadas. El rastreador puede admitir un máximo de 256 subprocesos por aplicación de servicio de búsqueda. Se recomienda tener un procesador de núcleo cuádruple para obtener todos los beneficios del número máximo de subprocesos. Cuando se determina manera concluyente que el repositorio está proporcionando datos con suficiente rapidez (vea la sección "Cuello de botella de rastreo en el repositorio" más adelante en este artículo), se puede aumentar el rendimiento de rastreo solicitando datos más rápidamente desde el repositorio mediante el aumento del número de subprocesos del rastreador. Esto se puede lograr de tres maneras, tal como se indica a continuación:

1. Cambie el nivel de rendimiento del indizador a Maximum o Partially Reduced mediante el siguiente cmdlet de Windows PowerShell:

   • Get-SPEnterpriseSearchService | Set-SPEnterpriseSearchService –PerformanceLevel “Maximum”

     Se usa el valor Maximum si va a usar un procesador con menos de cuatro núcleos.

2. Use reglas de impacto del rastreador para aumentar el número de subprocesos por host. Se debe tener en cuenta que se admite un máximo de 256 subprocesos y la asignación de un gran número de subprocesos a pocos hosts puede dar lugar a una recuperación de datos más lenta desde otros repositorios.

3. Si hay un gran número de hosts, la solución ideal es agregar otro componente de rastreo en un indizador independiente para rastrear los hosts que se deben indizar con mayor rapidez.

La forma ideal de aumentar sin problemas el rendimiento de rastreo es agregar otro indizador si el subsistema de búsqueda no tiene un cuello de botella en IOPS y el repositorio está proporcionando contenido rápidamente.

Cuello de botella de rastreo en el repositorio

A veces, cuando se rastrea una aplicación web de SharePoint con muchos recursos compartidos de archivos remotos o colecciones de sitios anidadas, el rastreador de búsqueda podría desarrollar un cuello de botella en el repositorio. Un cuello de botella de repositorio puede identificarse si las siguientes dos condiciones son verdaderas:

• El uso de CPU es bajo (menos de 20%) en los servidores de rastreo.

• Hay un gran número de subprocesos (casi todos en el peor de los casos) en espera en la red.

  El cuello de botella se identifica analizando el contador de rendimiento Recopilador de OSS Search o Subprocesos con acceso a la red.

Lo que representa esta situación es que los subprocesos se bloquean mientras se esperan los datos del repositorio. En un entorno con varios orígenes de contenido, puede resultar útil identificar el host cuya capacidad de respuesta es lenta pausando los demás rastreos y, a continuación, realizando un rastreo con el origen de contenido que tiene el host sospechoso como una de su direcciones de inicio.

Cuando se identifica un host problemático, debe investigar la causa de los tiempos de respuesta lentos. Para obtener información de contenido de SharePoint en particular, vea el artículo Administración y ajuste de tamaño de la capacidad de SharePoint Server 2010.

El rendimiento de rastreo se puede mejorar considerablemente mediante el ajuste del rendimiento de los repositorios de datos rastreados.

Problemas de escala y solución de problemas de rendimiento

Es fundamental comprender la carga en la granja de servidores para poder solucionar problemas de rendimiento. En la siguiente sección, se usan datos de una granja de servidores activa que contiene 60 millones de elementos para mostrar diversas métricas del sistema en distintas fases del ciclo de vida de la búsqueda.

Ejemplos de rendimiento durante el ciclo de vida de la búsqueda

Métrica	Adquisición de índices	Mantenimiento de índices	Limpieza de índices
CPU de SQL Server (en %) Base de datos de propiedades / base de datos de rastreo	14,8 / 19,13	35 / 55	11 / 63
Duración prevista de la página de SQL Server Base de datos de propiedades / base de datos de rastreo	60.548 / 5.913	83.366 / 5.373	33.927 / 2.806
Promedio de segundos de disco/escritura de SQL Server Base de datos de propiedades / base de datos de rastreo	9 ms / 48 ms MÁX: 466 ms / 1.277 ms	12 ms / 28 ms	20 ms / 49 ms MÁX: 253 ms / 1156 ms
Promedio de segundos de disco/lectura de SQL Server Base de datos de propiedades / base de datos de rastreo	8 ms / 43 ms MÁX: 1.362 ms / 2.688 ms	11 ms / 24 ms	24 ms / 29 ms MÁX: 2.039 ms / 2.142 ms
CPU de rastreador (en %) Servidor de índice 1 (2 componentes de rastreo) / Servidor de índice 2 (2 componentes de rastreo)	18 / 11	25,76 / 21,62	8,34 / 7,49 Picos máximos en 99%
Escrituras en disco/s Servidor de índice 1 (2 componentes de rastreo) / Servidor de índice 2 (2 componentes de rastreo)	64,32 / 42,35	93,31 / 92,45	99,81 / 110,98
Lecturas de disco/s Servidor de índice 1 (2 componentes de rastreo) / Servidor de índice 2 (2 componentes de rastreo)	0,23 / 0,20	4,92 / 2,03	1,38 / 1,97
Promedio de segundos de disco/escritura Servidor de índice 1 (2 componentes de rastreo) / Servidor de índice 2 (2 componentes de rastreo)	11 ms / 11 ms	1 ms / 2 ms	5 ms / 4 ms MÁX: 1.962 ms / 3.235 ms
Promedio de segundos de disco/lectura Servidor de índice 1 (2 componentes de rastreo) / Servidor de índice 2 (2 componentes de rastreo)	1 ms / 2 ms	12 ms / 11 ms	10 ms / 16 ms MÁX: 2.366 ms / 5.206 ms

Solución de problemas de rendimiento de consulta

La búsqueda de SharePoint tiene una canalización de consultas instrumentadas e informes de administración asociados que pueden ayudar a solucionar problemas de rendimiento de consultas en el servidor. Para obtener más información, vea Uso de informes de administración de búsquedas (SharePoint Server 2010). Esta sección muestra informes y, a continuación, los usa para ayudar a comprender cómo solucionar problemas en el servidor. Además, esta sección también contiene herramientas y asistencia que está disponible para ayudar a afrontar problemas de rendimiento basados en el cliente (explorador).

Problemas de consultas en el servidor

Los problemas de rendimiento de consultas en el servidor se pueden separar en los dos niveles siguientes:

• Problemas de rendimiento de front-end de búsqueda

• Problemas de rendimiento de back-end de búsqueda

En las siguientes dos subsecciones se proporcionan los detalles para solucionar problemas de cada uno de ellos. Tenga en cuenta que son instrucciones de alto nivel.

Problemas de rendimiento de front-end

El primer paso para solucionar problemas de rendimiento de front-end debe ser la revisión del informe de administración de búsqueda Latencia de consulta general. A continuación, se presenta un informe de ejemplo:

En este informe, el rendimiento de front-end se representa mediante la siguiente serie de datos:

• Representación de servidor: este valor representa, para determinado minuto, el tiempo promedio empleado por consulta en los diversos elementos web de búsqueda en el servidor front-end web.

• Modelo de objetos: este valor representa, para determinado minuto, el tiempo promedio empleado en la comunicación entre el servidor front-end web y el back-end de búsqueda.

Solución de problemas de representación de servidor

Los problemas de representación de servidor pueden verse afectados por todo lo que se produce en el servidor front-end web que proporciona la página de resultados de búsqueda. En general, desea comprender cuánto tiempo dedica a recuperar los diversos elementos web para ver dónde se agrega la latencia adicional. Habilite el Panel del programador en la página de resultados de búsqueda para obtener informes detallados de latencia. Entre los problemas comunes que se manifiestan como exceso de latencia de representación de servidor, se incluyen los siguientes:

• Problemas de plataforma como los siguientes:

  • Búsquedas lentas en Active Directory

  • Tiempos lentos en SQL Server

  • Solicitudes lentas a la aplicación de perfil de usuario en consultas de usuarios en SharePoint Server 2010 o todas las consultas en FAST Search Server 2010 for SharePoint

  • Solicitudes lentas para capturar las preferencias del usuario

  • Llamadas lentas para obtener el token del usuario del servicio de token de seguridad

• Problemas de código subyacente como páginas modificadas de resultados de búsqueda (como results.aspx y peopleresults.aspx) que están protegidas, pero no publicadas.

Solución de problemas del modelo de objetos

Los problemas del modelo de objetos se pueden ver afectados por lo siguiente:

• Problemas con la capa de Windows Communication Foundation (WCF) como los siguientes:

  • Tiempos de espera y excepciones threadabortexception en llamadas WCF en la implementación.

  • Comunicación lenta entre el servidor front-end web y el servidor de aplicaciones. Esto se puede deber a problemas de IPsec o conexiones de red lentas.

• Problemas con la comunicación entre las granjas de servidores de servicio y contenido (si están configuradas).

Problemas de rendimiento de back-end

El primer paso para solucionar problemas de rendimiento de consulta de back-end debe ser la revisión del informe de administración de búsqueda Latencia de consulta del back-end de SharePoint. A continuación, se presenta un informe de ejemplo:

En este informe, el rendimiento de back-end se representa mediante la siguiente serie de datos (cada uno es el tiempo promedio empleado por consulta, en determinado minuto), agrupado por el componente funcional:

• Componente de consulta:

  • Consulta de texto: el tiempo promedio empleado en consultar el índice de texto completo para obtener resultados.

• Base de datos de propiedades:

  • Recuperación de resultados múltiples: el tiempo promedio empleado en recuperar metadatos del documento, como título o autor, para que aparezcan en los resultados de la consulta.

  • Consulta del almacén de propiedades: el tiempo promedio empleado en consultar la base de datos de propiedades para las consultas basadas en propiedades.

• Base de datos de administración de búsqueda:

  • Opciones más probables: el tiempo promedio empleado en determinar si hay opciones más probables disponibles para los términos de la consulta.

  • Resultados de alta confianza: el tiempo promedio empleado en recuperar resultados de alta confianza para las consultas.

• Procesador de consultas:

  • Recorte de seguridad: el tiempo promedio empleado en quitar los elementos a los que el usuario no tiene acceso.

  • Eliminación de duplicados: el tiempo promedio empleado en quitar duplicados.

  • Rellenado de resultados: el tiempo promedio empleado en la creación de la tabla en memoria que se va a pasar al modelo de objetos.

Solución de problemas de rendimiento de componentes de consulta

Los componentes de consulta usan una gran cantidad de recursos, especialmente cuando el componente está activo, es decir, responde a las solicitudes de consultas. La solución de problemas de rendimiento de componentes de consulta es una de las áreas de búsqueda más complicadas. A continuación, se presentan las áreas generales que hay que tener en cuenta:

• El evento de componente de consulta que usa más recursos es la combinación maestra, donde los índices secundarios se combinan con el índice maestro. Este evento se produce de forma independiente para cada componente de consulta. Se puede ver un ejemplo del efecto en el informe Latencia de consulta del back-end de SharePoint mencionado anteriormente en este artículo, antes de la 1:30 p.m. Si este evento está afectando a la latencia de consulta, es posible definir períodos sin disponibilidad durante los cuales se evita un evento de combinación maestra a menos que el porcentaje de cambio supere el límite definido.

• Los valores altos constantes del entorno indican que probablemente debería hacer lo siguiente:

  • Examine el tamaño del índice para cada componente en el servidor. Asegúrese de que existe suficiente memoria RAM en el servidor para permitir que aproximadamente el 33% de la suma de los tamaños de índice se almacene en caché.

  • Examine el canal de E/S del componente de consulta en el servidor. Asegúrese de que no está experimentando un cuello de botella de E/S.

  • Si el E/S y la memoria RAM no son el origen del problema de rendimiento, debe crear particiones de los componentes de consulta (agregando particiones de índice), mediante el escalado horizontal de los componentes de consulta adicionales en los nuevos servidores.

Solución de problemas de base de datos de propiedades

Examine el mantenimiento de SQL Server mediante los conceptos presentes en Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010). Si está ejecutando consultas personalizadas, es posible que deba mirar las sugerencias para guiar el plan de consultas correcto.

Solución de problemas de base de datos de administración de búsqueda

Examine el mantenimiento de SQL Server mediante los conceptos presentes en Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010).

Solución de problemas de procesador de consultas

La solución de problemas de procesador de consultas depende de cuál de las siguientes áreas del procesador de consultas está afectando a la latencia de consulta:

• Recorte de seguridad:

  • Para las notificaciones de Windows, examine la conexión de Active Directory desde el servidor que hospeda el procesador de consultas.

  • Para todos los casos, el tamaño de la memoria caché que usa el procesador de consultas se puede aumentar si hay una correlación entre un gran número de ciclos de ida y vuelta de SQL Server (determinado por SQL Server Profiler). Más del 25% de las consultas no debe necesitar una llamada de SQL Server para recuperar los descriptores de seguridad de la base de datos de administración de búsqueda. Si no es así, ajuste el tamaño de la memoria caché del procesador de consultas.

• Eliminación de duplicados:

  • Observe si está rastreando el mismo contenido en varios lugares. Deshabilite la detección de duplicados en el Centro de búsqueda.

• Recuperación de resultados múltiples:

  • Examine el mantenimiento de SQL Server mediante los conceptos presentes en Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010).

Problemas de consultas basadas en el explorador

Los usuarios pueden sentirse encantados o exasperados por la velocidad de los resultados de búsqueda. El tiempo de carga de la página es uno de los factores importantes en la satisfacción de los usuarios con la experiencia de búsqueda. Casi toda la atención en torno al tiempo de carga de la página está en el servidor, específicamente en el tiempo que tarda el servidor en devolver resultados. Sin embargo, la representación del lado cliente puede formar una parte considerable del tiempo de carga de la página y es importante tenerla en cuenta.

La experiencia de búsqueda del usuario está diseñada para proporcionar respuestas de fracciones de segundo para el tiempo de carga total de la página. Fuera de ese tiempo, la representación del lado cliente suele tardar menos de 280 milisegundos, según el explorador y la medida de la representación. Esta experiencia ofrece a los usuarios resultados muy rápidos.

Las personalizaciones de la experiencia de los resultados pueden degradar fácilmente el rendimiento de la representación. Los programadores y administradores de la búsqueda deben estar atentos al medir el tiempo de representación después de cada modificación para asegurarse de que el rendimiento no haya experimentado un retroceso significativo. Cada adición a la página, desde un nuevo elemento web hasta un nuevo estilo de hoja de estilos en cascada, aumentará el tiempo de representación en el explorador y retrasará los resultados para los usuarios. Sin embargo, el tiempo de retraso puede variar considerablemente en función de si se siguen los procedimientos recomendados al personalizar la página.

Estas son algunas instrucciones generales:

• Las personalizaciones de estilo y personalizaciones básicas de marca en la página no deberían agregar más de aproximadamente 25 ms al tiempo de carga de la página. Mida el tiempo de carga de la página antes y después de implementar las personalizaciones para observar el cambio.

• Los usuarios suelen observar un cambio (más rápido o más lento) en un incremento de 20%. Téngalo en cuenta al realizar cambios. El 20% del tiempo de representación estándar es de solo 50 ms. (Fuente: Designing and Engineering Time)

• Las hojas de estilos en cascada y JScript son las causas más grandes y comunes del alto rendimiento de representación. Si debe tener JScript y hojas de estilos en cascada personalizadas, asegúrese de que se minimizan en un archivo cada una.

• JScript se puede cargar a petición después de que la página se presenta para proporcionar cuanto antes resultados visibles al usuario. En el artículo de consideraciones de rendimiento, se describen los detalles de cómo hacerlo.

• Cuantas más personalizaciones se agreguen a la página, más lenta será la carga. Considere si el estilo y la funcionalidad agregados hacen que merezca la pena el retraso adicional de los resultados para los usuarios.

Además de estas instrucciones, hay una gran cantidad de información en Internet acerca de cómo reducir el tiempo de carga de la página y sobre el efecto de las páginas lentas en la experiencia del usuario.

Solución de problemas de rendimiento de rastreo

La búsqueda de SharePoint puede experimentar cuellos de botella en el subsistema de rastreo, a medida que el sistema se desplaza a través de las fases de adquisición, mantenimiento y eliminación de índices. Para solucionar de manera eficaz los problemas de rendimiento de rastreo, se deben usar los informes de seguimiento de estado de búsqueda con la sección "Cuellos de botella comunes y sus causas" más adelante en este artículo a fin de aislar los problemas de rastreo.

Solución de problemas durante la fase de adquisición de índices

El primer lugar para identificar problemas de rastreo es el informe de mantenimiento Tasa de rastreo por origen de contenido. Como se muestra más adelante en este artículo, el informe proporciona información general acerca de la tasa de rastreo para cada uno de los orígenes de contenido del sistema. En general, la tasa de rastreo debe ser de más de 15 documentos por segundo para un origen de contenido de usuarios y de más de 35 documentos por segundo para todos los demás tipos de orígenes de contenido.

Cuando se identifica un origen de contenido con una tasa de rastreo poco óptima, se recomiendan los siguientes pasos:

1. Pause los demás rastreos excepto el origen de contenido que se está investigando. ¿Mejoró la tasa de rastreo por encima del objetivo especificado de 15 a 35 documentos por segundo?

2. Si el paso anterior no soluciona el problema, asegúrese de que el repositorio que se va a rastrear responde lo suficiente y no es la causa del rastreo lento. Consulte la sección "Cuello de botella de rastreo en el repositorio" anteriormente en este artículo.

3. Si el repositorio no es el cuello de botella, identifique el cuello de botella en el servidor de rastreo o servidor de bases de datos y optimícelos. Puede encontrar ayuda en las secciones "Cuello de botella de IOPS de rastreo" y "Cuello de botella de subprocesos de CPU de rastreo" anteriormente en este artículo.

Solución de problemas durante la fase de mantenimiento de índices

El objetivo principal durante la fase de mantenimiento de índices es mantener el índice lo más actualizado posible. Dos de los indicadores clave son los siguientes:

• Actualización del índice: ¿están terminando los rastreos en el tiempo presupuestado y de acuerdo con las directrices de TI para la actualización de índices?

• Velocidad de rastreo incremental: si no se cumple el objetivo de actualización del índice, investigue si las velocidades de rastreo incremental son de 10 documentos por segundo para los orígenes de contenido de usuarios y 35 documentos por segundo para los demás orígenes de contenido. Si las velocidades de rastreo incremental son poco óptimas, se debe realizar un análisis de cuello de botella en el repositorio rastreado y el subsistema de rastreo, tal como se describió anteriormente.

Cuellos de botella comunes y sus causas

Durante las pruebas de rendimiento, se detectaron distintos cuellos de botella habituales. Un cuello de botella es una situación en la que se alcanza la capacidad máxima de un componente determinado de una granja de servidores. Esto produce un estancamiento o una disminución en el rendimiento de la granja de servidores.

En la siguiente tabla se enumeran algunos cuellos de botella comunes y se describen sus causas y soluciones posibles.

Cuellos de botella	Síntoma (contador de rendimiento)	Resolución
RAM de la base de datos	Base de datos de propiedades, base de datos de administración de búsqueda presentan lo siguiente: Administrador de búfer de SQL Server/duración prevista de la página < 300(s) (debe ser > 1000 (s)) Administrador de búfer de SQL Server/frecuencia de aciertos de caché del búfer < 96% (debe ser > 98%)	Agregue memoria al servidor de bases de datos. Desfragmente la base de datos de propiedades si la regla de desfragmentación semanal se ha deshabilitado. Asegúrese de que está usando SQL Server 2008 Enterprise Edition, a fin de habilitar la compresión de página. Mueva la base de datos a un servidor independiente y agregue varias bases de datos de propiedades, si son necesarias.
IOPS de servidor de bases de datos	Una base de datos de propiedades o base de datos de rastreo presenta lo siguiente: Promedio de segundos de disco/lectura y promedio de segundos de disco/escritura ~50 ms o > 50 ms	Asegúrese de que el servidor de bases de datos tiene suficiente memoria RAM para mantener un 33% de las tablas críticas (MSSDocSDIDs + MSSDocProps + MSSDocresults) en la memoria caché. Aumente el número dedicado de IOPS para la base de datos mediante el siguiente procedimiento: Use diferentes matrices de almacenamiento. Optimice la configuración de almacenamiento; por ejemplo, mediante la adición de cilindros (unidades de disco) a la matriz de almacenamiento. Ejecute la regla Búsqueda - Una o más bases de datos de propiedades tienen índices fragmentados del analizador de mantenimiento de SharePoint si se ha deshabilitado. Ejecute la regla Búsqueda - Una o más bases de datos de propiedades tienen índices fragmentados del analizador de mantenimiento de SharePoint. Asegúrese de que está usando SQL Server 2008 Enterprise Edition, a fin de habilitar la compresión de página. Mueva la base de datos a un servidor independiente, agregando varias bases de datos de propiedades, bases de datos de rastreo o ambas, si son necesarias.
IOPS de componente de consulta	El disco lógico que se usa para el índice de un componente de consulta presenta lo siguiente: Promedio de segundos de disco/lectura y promedio de segundos de disco/escritura ~30 ms o > 30 ms para un período continuo de tiempo (es decir, la mayor parte del día; no solo durante una combinación de índices).	Asegúrese de que cada servidor de aplicaciones tiene suficiente memoria RAM para mantener un 33% del índice de cada componente de consulta activo (en ese servidor) en la memoria caché (caché del sistema operativo). Aumente el número dedicado de IOPS para la unidad que se usa para el índice del componente de consulta mediante el siguiente procedimiento: Use diferentes matrices de almacenamiento para diferentes componentes. Optimice la configuración de almacenamiento; por ejemplo, mediante la adición de cilindros (unidades de disco) a la matriz de almacenamiento.

Acerca del autor

Brion Stone es un jefe de programas sénior de búsqueda de SharePoint Server en Microsoft.