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.

Proporción de palabras clave con respecto a términos

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.

RPS frente a longitud de etiqueta

En los gráficos siguientes, se muestra el uso de CPU y memoria.

Uso de CPU Uso de RAM

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.

RPS Uso de CPU

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.

Tiempo para crear palabra clave

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.

RPS medio

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.

Uso medio de CPU Uso medio de RAM

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.

Promedio de términos creados por minuto en RPS

En los dos gráficos siguientes, se muestra el uso de CPU y memoria.

Promedio de términos creados por minuto en CPU Promedio de términos creados por minuto en RAM

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.

Tamaño de caché frente a número de términos visualizados

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.

RPS para dos aplicaciones de servicio

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.

Latencia de sugerencias de palabras clave

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.

Uso medio de CPU Uso medio de RAM

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.

Tiempos de sindicación frente a número de colecciones de sitios

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.

Tiempo de sindicación frente a número de tipos de contenido

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.

Tiempo medio para actualizar término

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.

Tiempo medio para actualizar un término en una 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.