Capacidad y rendimiento de metadatos administrados de empresa en SharePoint Server 2010
Se aplica a: SharePoint Server 2010
Última modificación del tema: 2016-11-30
En este artículo se ofrecen recomendaciones relacionadas con la optimización del rendimiento y del tamaño del servicio de metadatos administrados en Microsoft SharePoint Server 2010. También se proporcionan procedimientos recomendados acerca de cómo configurar el servicio y estructurar las bases de datos de la aplicación de servicio para obtener el máximo rendimiento.
La información de este artículo puede ayudarle a comprender los límites de rendimiento y capacidad probados del servicio de metadatos administrados. Use esta información para determinar si la implementación planeada está dentro de límites de capacidad y rendimiento aceptables.
En este artículo:
Características de la granja de servidores de la prueba
Resultados de las pruebas y recomendaciones
Para obtener información general acerca de la administración de capacidad y cómo planear SharePoint Server 2010, vea Administración y ajuste de tamaño de la capacidad de SharePoint Server 2010.
Características de la granja de servidores de la prueba
Conjunto de datos
En primer lugar, las pruebas se ejecutaron en el conjunto de datos de línea base, que simula un conjunto de datos de cliente típico. A continuación, se cambió una sola variable y se volvieron a ejecutar las mismas pruebas para determinar el efecto que tenía el cambio de esa variable en el rendimiento. En la mayoría de los casos, se probaron las variables por separado. Sin embargo, en algunos casos, determinadas variables importantes se probaron en combinación.
Conjunto de datos de línea base
El conjunto de datos de línea base contiene los datos que se muestran en la tabla siguiente.
Datos | Detalle |
---|---|
Grupos de conjuntos de términos |
100 |
Conjuntos de términos |
1.000 (10 por grupo) |
Términos administrados (no incluye palabras clave de empresa) |
20.000 (20 por conjunto de términos) |
Palabras clave de empresa |
80.000 |
Términos totales (incluye términos administrados y palabras clave de empresa) |
100.000 |
Etiquetas |
100.000 (1 por término) |
Longitud de etiqueta de término |
250 caracteres por etiqueta |
En el gráfico siguiente se muestra el número de términos del conjunto de datos de línea base.
En estas pruebas, la relación entre las palabras clave y los términos administrados es siempre 4:1 en todos los conjuntos de datos.
Carga de trabajo
Varias características clave del servicio de metadatos administrados pueden afectar potencialmente al rendimiento del servicio. A continuación se proporcionan algunas de estas características:
Características de los datos en el servicio
Longitud de etiqueta de término
Número de términos por almacén de términos
Número de etiquetas de término por almacén de términos
Características de la carga en el servicio
- Combinación de lectura y escritura
Tamaño de memoria caché de almacén de términos
Número de aplicaciones de servicio por servidor de bases de datos
Rendimiento de los trabajos de temporizador de servicios (concentrador de tipo de contenido, suscriptor de tipo de contenido, actualización de datos del sitio de metadatos de empresa, programador de actualización de taxonomía)
Los resultados de pruebas específicos de rendimiento y capacidad presentados en este artículo podrían diferir de los resultados de pruebas en entornos reales y están pensados para proporcionar un punto de partida para el diseño de un entorno adecuadamente escalado. Una vez completado el diseño inicial del sistema, pruebe la configuración para determinar si el sistema admitirá el modo en que configuró el servicio de metadatos administrados en el entorno.
Escenarios de prueba
A continuación se enumeran las pruebas que se usaron para cada escenario de prueba:
Crear un término (prueba de escritura)
Esta prueba crea un término en un conjunto de términos existente.
Obtener sugerencias (prueba de solo lectura)
Esta prueba busca términos que comiencen con una única cadena de caracteres, tal como se usan en la recuperación de sugerencias del campo de palabras clave.
Obtener coincidencias (prueba de solo lectura)
Esta prueba busca términos que coincidan con una cadena proporcionada, como en la coincidencia de valor del campo de palabras clave o el campo de metadatos.
Obtener términos secundarios de un conjunto de términos mediante paginación (prueba de solo lectura)
Esta prueba devuelve términos secundarios de un conjunto de términos mediante paginación.
Validar un término (prueba de solo lectura)
Esta prueba valida un único término, como en la validación de valor del campo de palabras clave o el campo de metadatos.
Combinación de pruebas
La mayoría de las pruebas (excepto las pruebas de los efectos de las operaciones de escritura) usaron la misma combinación de operaciones de lectura y escritura, que se muestra en la tabla siguiente.
Prueba | Porcentaje de combinación |
---|---|
Crear un término |
0,125% |
Obtener sugerencias |
72,875% |
Obtener coincidencias |
11% |
Obtener términos secundarios de un conjunto de términos mediante paginación |
5% |
Validar un término |
11% |
"Obtener sugerencias" es la operación del usuario final más usada. Es por eso que se pondera de forma considerable en la combinación de pruebas.
Hardware, configuración y topología
La granja de servidores de prueba tiene tres servidores; cada uno de ellos es único e independiente para el servidor web, el servidor de aplicaciones y el servidor de bases de datos.
Servidor web y servidor de aplicaciones
El servidor web y el servidor de aplicaciones usan hardware idéntico y están configurados como se muestra en la tabla siguiente.
Componente | Configuración del servidor web y el servidor de aplicaciones |
---|---|
Procesadores |
Dos procesadores de cuatro núcleos de 2,33 GHz cada uno |
RAM |
8 Gigabytes (GB) |
Sistema operativo |
Windows Server 2008 de 64 bits |
Tamaño de la unidad de sistema |
300 GB |
Número de adaptadores de red |
Dos |
Velocidad del adaptador de red |
1 gigabit por segundo |
Autenticación |
Básica de Windows |
Versión de software |
SharePoint Server 2010 Nota El resultado puede variar en función de qué versión se use. |
Servicios que se ejecutan localmente |
Administración central Correo electrónico entrante de Microsoft SharePoint Foundation Aplicación web de Microsoft SharePoint Foundation Servicio de temporizador de flujo de trabajo de Microsoft SharePoint Foundation |
Servidor de bases de datos
El servidor de base de datos está configurado como se muestra en la tabla siguiente.
Componente | Configuración del servidor de bases de datos |
---|---|
Procesadores |
Cuatro procesadores de cuatro núcleos de 3,19 GHz cada uno |
RAM |
16 Gigabytes (GB) |
Sistema operativo |
Windows Server 2008 de 64 bits |
Almacenamiento |
15 discos de 300 GB a 15.000 rpm cada uno |
Número de adaptadores de red |
Dos |
Velocidad del adaptador de red |
1 gigabit por segundo |
Autenticación |
Windows NTLM |
Versión de software |
Microsoft SQL Server 2008 |
Resultados de las pruebas y recomendaciones
En esta sección se describen los resultados de pruebas y se proporcionan recomendaciones para las siguientes características:
Características de los datos
Características de la carga
Rendimiento de los trabajos de temporizador
Características de los datos
Efecto de la longitud de etiqueta de término
En primer lugar, estas pruebas se realizaron en el almacén de términos de línea base con una longitud de etiqueta de 5 caracteres. Luego se volvieron a realizar con una longitud de etiqueta de término de 250 caracteres. En esta prueba, las operaciones de escritura representan un porcentaje mucho mayor del total que la combinación de operaciones de lectura y escritura que se usó para la mayoría de las otras pruebas.
Prueba | Porcentaje de combinación |
---|---|
Crear un término |
5% |
Obtener sugerencias |
70% |
Obtener coincidencias |
10% |
Obtener términos secundarios de un conjunto de términos mediante paginación |
5% |
Validar un término |
10% |
En el gráfico siguiente, se muestran los resultados de solicitudes por segundo (RPS) para las distintas longitudes de etiqueta de término. Estos datos sugieren que la longitud de etiqueta de término no tiene un efecto significativo en el promedio de RPS para ambas cargas.
En los gráficos siguientes, se muestra el uso de CPU y memoria.
Como indican los resultados, el efecto de la longitud de la etiqueta de término en el uso de CPU y memoria para el servidor web y el servidor de aplicaciones es insignificante. Sin embargo, la carga en el servidor de base de datos aumenta a medida que se incrementa la longitud de la etiqueta de término.
Conclusiones y recomendaciones: longitud de etiqueta de término
La longitud de la etiqueta de término no tiene un efecto significativo en el rendimiento del sistema.
Términos por almacén de términos
Estas pruebas se realizaron en el almacén de términos de línea base y después se incrementó la escalabilidad vertical del almacén de términos hasta un millón de términos mediante el aumento proporcional del número de palabras clave y términos administrados.
Cuando el conjunto de términos de palabras clave se quitó del almacén de términos para realizar las pruebas, la diferencia entre el rendimiento de un almacén de términos con 100.000 términos, un almacén de términos con 500.000 términos y un almacén de términos con un millón de términos no fue significativa, como se muestra en los dos gráficos siguientes.
Cuando el sistema está bajo la carga de prueba especificada, el tiempo necesario para crear una palabra clave aumenta significativamente a medida que se incrementa el número de palabras clave de 16.000 a 800.000. Esta tendencia puede verse en el gráfico siguiente.
Conclusiones y recomendaciones: términos por almacén de términos
El número de términos en un almacén de términos no afecta significativamente al rendimiento del sistema cuando muy pocos usuarios crean palabras clave o cuando el número de palabras clave es pequeño.
El conjunto de términos de palabras clave se almacena en una lista plana, a diferencia de otros conjuntos de términos que tienen una estructura más compleja. Cuanto más grande sea la lista plana, más tiempo se tardará para comprobar si ya hay una palabra clave que tenga el mismo nombre. Por lo tanto, se tarda más en crear una palabra clave en un conjunto de términos de palabras clave de gran tamaño.
El administrador del almacén de términos debería limitar el tamaño del conjunto de términos de palabras clave para evitar la latencia cuando los usuarios crean los términos de palabra clave. Un enfoque es mover con frecuencia las palabras clave de un conjunto de términos regular, lo cual puede mejorar el rendimiento y contribuir a una mejor organización de los datos de términos.
Cualquier conjunto de términos que contenga más de 150.000 términos en una lista plana está sujeto a problemas de latencia y rendimiento. Una alternativa es usar un conjunto de términos administrados, que normalmente tiene una colección de términos estructurada. Para obtener más información acerca de los conjuntos de términos, vea Introducción a los metadatos administrados.
Errores comunes
A medida que el número total de términos en el almacén de términos se acerca a 500.000, los usuarios podrían experimentar diferentes excepciones al intentar acceder al almacén de términos. Al comprobar el registro del Servicio de creación de registros unificado (ULS) relacionado, el administrador de la granja de servidores podría encontrar la excepción y determinar si se aplica al cliente o al servidor.
TimeoutException
Cuando se producen errores de TimeoutException, puede modificar el valor del tiempo de espera en el archivo client.config o en el archivo web.config para el servicio de metadatos administrados. El archivo client.config puede encontrarse en la carpeta %PROGRAMFILES%\Microsoft Office Servers\14.0\WebClients\Metadata. El archivo web.config puede encontrarse en la carpeta %PROGRAMFILES%\Microsoft Office Servers\14.0\WebServices\Metadata. Hay cuatro valores de tiempo de espera:
receiveTimeout : un valor de tiempo de espera que especifica el intervalo de tiempo proporcionado para completar una operación de recepción.
sendTimeout: un valor de tiempo de espera que especifica el intervalo de tiempo proporcionado para completar una operación de envío.
openTimeout: un valor de tiempo de espera que especifica el intervalo de tiempo proporcionado para completar una operación de apertura.
closeTimeout: un valor de tiempo de espera que especifica el intervalo de tiempo proporcionado para completar una operación de cierre.
Estos valores de tiempo de espera se definen en la sección customBinding. Puede aumentar el valor del tiempo de espera en función de la operación específica que agota el tiempo de espera. Por ejemplo, si el tiempo de espera se agota cuando se reciben mensajes, solo necesita aumentar el valor de ReceiveTimeout.
Nota
Hay valores de tiempo de espera para HTTP y HTTPS y, por tanto, debe modificar el valor de tiempo de espera para HTTP o HTTPS.
Para obtener más información acerca de los valores de tiempo de espera, vea <customBinding> (https://go.microsoft.com/fwlink/?linkid=214213&clcid=0xC0A).
ThreadAbortException
Cuando se producen errores de ThreadAbortException, puede aumentar el valor de tiempo de espera de ejecución en el archivo web.config para la aplicación web específica. El archivo web.config se encuentra en la carpeta %inetpub%\wwwroot\wss\VirtualDirectories\<númeroDePuertoDeAplicación>. Por ejemplo, si la solicitud es para TaxonomyInternalService en una aplicación web, identifique primero el archivo web.config de la aplicación web y, a continuación, agregue el código siguiente en el nodo de configuración.
<location path="_vti_bin/TaxonomyInternalService.json">
<system.web>
<httpRuntime executionTimeout="3600" />
</system.web>
</location>
Nota
El valor de executionTimeout predeterminado es de 360 segundos.
Etiquetas de término por almacén de términos
Esta prueba se realizó en un almacén de términos de línea base que tenía 100.000 términos. Durante la prueba, se incrementó el número de etiquetas para cada término, tal como se muestra en el gráfico siguiente.
El promedio de RPS disminuye solo ligeramente a medida que el número de etiquetas aumenta. El uso de CPU y memoria en el servidor web, el servidor de aplicaciones y el servidor de bases de datos aumenta solo ligeramente, tal como se muestra en los gráficos siguientes.
Conclusiones y recomendaciones: etiquetas de término por almacén de términos
El número de etiquetas no tiene un efecto significativo en el rendimiento del sistema cuando el número promedio de etiquetas por término es inferior a cuatro.
Resumen: características de datos
En esta sección se revisan los resultados de pruebas para tres características diferentes de datos del almacén de términos: la longitud de etiqueta de término, el número de términos por almacén de términos y el número de etiquetas de término por almacén de términos. A continuación, se enumeran las tendencias que reveló esta prueba:
El aumento de la longitud de etiqueta de término a 250 no tiene un efecto significativo en el rendimiento del almacén de términos.
El aumento del número promedio de etiquetas por término a cuatro no tiene un efecto significativo en el rendimiento del almacén de términos.
El aumento del número de términos a un millón no tiene un efecto significativo en el rendimiento del almacén de términos.
Cuando el almacén de términos contiene más de 150.000 términos en un conjunto de términos que usa una lista plana, puede tardarse mucho tiempo en agregar nuevos términos al almacén de términos.
Características de carga
Impacto de los cambios en la combinación de lectura y escritura
Estas pruebas se realizaron mediante la combinación de pruebas de línea base de operaciones de lectura y escritura con la prueba "Crear elemento de taxonomía" como el elemento que varía. En la siguiente tabla se muestran las operaciones específicas que se usaron en la combinación de pruebas de línea base y sus porcentajes asociados.
Prueba | Porcentaje de carga |
---|---|
Obtener sugerencias |
73% |
Crear elemento de taxonomía |
0% |
Obtener coincidencias |
11% |
Obtener términos secundarios paginados de un conjunto de términos |
5% |
Validar un término |
11% |
Para cada prueba sucesiva, se incrementó el número de términos creados. En la siguiente tabla se muestran las tres pruebas que se realizaron mediante la observación del promedio de términos creados por minuto. A continuación, se obtuvo el promedio de RPS.
Promedio de términos creados por minuto | RPS medio |
---|---|
0 |
182 |
8,4 |
157 |
20 |
139 |
Como se muestra en el siguiente gráfico, RPS disminuye a medida que el número promedio de términos creados por minuto aumenta.
En los dos gráficos siguientes, se muestra el uso de CPU y memoria.
Conclusiones y recomendaciones: impacto de los cambios en la combinación de lectura y escritura
Se espera que el rendimiento del almacén de términos disminuya a medida que aumenta el porcentaje de operaciones de escritura; debido a que las operaciones de escritura mantienen más bloqueos exclusivos en los datos, estas retrasan la ejecución de las operaciones de lectura. Según los datos de pruebas, RPS no disminuye significativamente hasta que el número promedio de términos creados alcanza los 20 por minuto. Sin embargo, una tasa promedio de creación de términos de 20 por minuto es bastante alta y, normalmente, no se produce; especialmente en un conjunto de términos antiguo. Si se establece un conjunto de términos como de solo lectura, se podría mejorar el rendimiento mediante la eliminación de las operaciones de escritura.
Memoria caché del almacén de términos
La memoria caché del almacén de términos está presente en todos los servidores web de una granja de servidores. Puede contener grupos de conjuntos de términos, conjuntos de términos y términos. Estas pruebas se realizaron para mostrar cómo cambia el consumo de memoria del objeto de caché a medida que aumenta el número de términos. Existen otros factores que afectan el tamaño de la memoria caché; por ejemplo, las descripciones de términos, el número de etiquetas y las propiedades personalizadas. Para simplificar la prueba, ninguno de los términos del almacén de términos de línea base tiene una descripción ni propiedades personalizadas y solo tienen una etiqueta con 250 caracteres.
En el siguiente gráfico se muestra cómo cambia el consumo de memoria a medida que el número de términos en la memoria caché aumenta.
Conclusiones y recomendaciones: memoria caché del almacén de términos
El uso de memoria en el servidor web se incrementa de forma lineal a medida que aumenta el número de términos en la memoria caché. Esto permite estimar el tamaño de la memoria caché si se conoce el número de términos. Según los datos de pruebas, el uso de memoria no debe ocasionar un problema de rendimiento para la mayoría de los sistemas.
Aplicaciones de servicio que consume una granja de servidores
Esta prueba muestra la diferencia de rendimiento entre una y dos aplicaciones de servicio de metadatos administrados cuyas bases de datos se hospedan en el mismo servidor de bases de datos.
Como se muestra en el siguiente gráfico, bajo la misma carga, RPS disminuye cuando se agrega una aplicación de servicio adicional. Se espera que RPS disminuya cuando se agreguen aplicaciones de servicio adicionales.
La latencia de la mayoría de las operaciones no se ve afectada de manera significativa cuando se agregan aplicaciones de servicio adicionales. Sin embargo, a diferencia de otras operaciones, la operación "obtener sugerencias" interactúa con todas las aplicaciones de servicio disponibles. Por lo tanto, la latencia para esta operación aumenta a medida que crece el número de aplicaciones de servicio, como se muestra en el siguiente gráfico. Se espera que esta tendencia continúe a medida que aumenta el número de aplicaciones de servicio.
Como se muestra en los gráficos siguientes, el uso de CPU del servidor de bases de datos aumenta considerablemente cuando hay dos aplicaciones de servicio que tienen bases de datos que residen en el mismo servidor, pero el uso de memoria no se incrementa de forma significativa.
Conclusiones y recomendaciones: aplicaciones de servicio que consume una granja de servidores
Si debe mantener más de una aplicación de servicio de metadatos administrados, asegúrese de que la latencia para las operaciones de sugerencia de palabras clave esté en un nivel aceptable. Tenga en cuenta que la latencia de red también contribuye a la latencia efectiva total. Se recomienda que las aplicaciones de servicio de metadatos administrados se consoliden en el mayor grado posible.
Si se usa un solo equipo de SQL Server para hospedar todas las aplicaciones de servicio, el servidor debe tener suficientes recursos de CPU y memoria para admitir objetivos de rendimiento aceptables.
Rendimiento de los trabajos de temporizador
En esta sección se muestran las características de rendimiento de dos trabajos de temporizador del servicio de metadatos administrados: suscriptor de tipo de contenido y programador de actualización de taxonomía. Ambos trabajos de temporizador enumeran las colecciones de sitios de una aplicación web y pueden ejecutarse potencialmente durante mucho tiempo y consumir muchos recursos del sistema en una granja de servidores de gran tamaño.
Trabajo de temporizador del suscriptor de tipo de contenido
El trabajo de temporizador del suscriptor de tipo de contenido distribuye los tipos de contenido publicados a todas las colecciones de sitios apropiadas de una aplicación web. El tiempo total que este trabajo de temporizador tarde en ejecutarse depende de muchos factores, como el número de tipos de contenido que se deben distribuir, el número y tipo de campos del tipo de contenido y el número de colecciones de sitios. Esta prueba muestra el modo en que los siguientes factores de escala afectan el tiempo total que se demora en distribuir un tipo de contenido:
El número de colecciones de sitios en una aplicación web
El número de tipos de contenido
La primera prueba se realizó mediante la publicación de 10 tipos de contenido y su distribución en un número diferente de colecciones de sitios. Como se muestra en el gráfico siguiente, la relación entre el tiempo de distribución de tipos de contenido y el número de colecciones de sitios es casi lineal.
En esta prueba, un tipo de contenido se publicó en 1.000 colecciones de sitios y, a continuación, se publicaron diez tipos de contenido en 1.000 colecciones de sitios. El tiempo de distribución para diez tipos de contenido es aproximadamente diez veces mayor que el tiempo de distribución para un tipo de contenido. Nuevamente, se muestra un aumento prácticamente lineal.
Conclusiones y recomendaciones: trabajo de temporizador del suscriptor de tipo de contenido
Los resultados de pruebas muestran que el tiempo promedio para distribuir un único tipo de contenido en una sola colección de sitios es casi una constante. Por lo tanto, es seguro ejecutar este trabajo de temporizador en una colección de colecciones de sitios de gran tamaño. Puede usar el tiempo promedio de distribución para estimar cuánto tardará en ejecutarse el trabajo de temporizador, en función del número de colecciones de sitios y el número de tipos de contenido que se debe distribuir. Si esos números son extremadamente grandes, es posible que se tarden horas o incluso días para ejecutar el trabajo de temporizador. No obstante, puede pausar y reanudar el trabajo. Además, la publicación de tipos de contenido no es una actividad muy frecuente.
Tenga en cuenta que el tiempo necesario para ejecutar este trabajo de temporizador puede aumentar considerablemente si se produce la inserción de un tipo de contenido durante el trabajo de temporizador, especialmente si intervienen muchas listas. Para obtener más información acerca de la inserción de tipos de contenido, vea la sección Conexión de metadatos administrados en Acerca de la aplicación de servicio de metadatos.
Sugerencia
Cuando intente publicar un tipo de contenido muy grande, es posible que vea el siguiente error:
WebException: se anuló la solicitud.
Esto ocurre porque el tamaño del tipo de contenido excede el tamaño de solicitud HTTP máximo predeterminado de 4 MB para la aplicación de servicio. Para evitar este error, puede aumentar el valor de maximumRequestLength en el archivo web.config de la aplicación de servicio.
Trabajo de temporizador del programador de actualización de taxonomía
El trabajo de temporizador del programador de actualización de taxonomía mantiene la lista de taxonomías oculta de cada colección de sitios de una aplicación web en sincronización con el almacén de términos. El tiempo total que este trabajo de temporizador tarda en ejecutarse depende del número de elementos que deben actualizarse y el número de colecciones de sitios que contienen elementos actualizados. Esta prueba muestra cómo el tamaño de la lista oculta y el número de colecciones de sitios de la aplicación web afecta el tiempo de actualización promedio de un único elemento de una colección de sitios.
En el siguiente gráfico se muestra la relación entre el número de colecciones de sitios y el tiempo promedio para actualizar un término de una colección de sitios.
Como se muestra en el gráfico siguiente, el tiempo promedio para actualizar un término de una colección de sitios aumenta ligeramente a medida que se incrementa el tamaño de la lista oculta.
Conclusiones y recomendaciones: trabajo de temporizador del programador de actualización de taxonomía
Un aumento en el número de colecciones de sitios no tiene un efecto significativo en el tiempo promedio para actualizar un término de una colección de sitios. Por lo tanto, es seguro ejecutar este trabajo de temporizador en una aplicación web que tenga un gran número de colecciones de sitios. Puede estimar el tiempo total de ejecución del trabajo de temporizador al multiplicar el tiempo promedio para actualizar un término de una colección de sitios por el número de colecciones de sitios y el número promedio de términos actualizados en cada colección de sitios. También puede pausar y reanudar este trabajo de temporizador.
El tamaño de la lista de taxonomías oculta aumenta con el tiempo, a medida que la colección de sitios usa más y más términos. El trabajo de temporizador podría tardar más en ejecutarse a medida que crece el tamaño de la lista oculta.