Estimación del planeamiento de capacidad y rendimiento para flujos de trabajo en SharePoint Server 2010

 

Se aplica a: SharePoint Server 2010

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

Este artículo sobre planeamiento de capacidad y rendimiento proporciona orientación sobre el efecto que tiene el uso de flujos de trabajo en las topologías que ejecutan Microsoft SharePoint Server 2010.

Para obtener información general acerca del planeamiento de capacidad de SharePoint Server 2010, vea Administración del rendimiento y de la capacidad (SharePoint Server 2010).

Contenido

• Prueba de las características de la granja de servidores

• Resultados de las pruebas

• Recomendaciones

• Solución de problemas

Prueba de las características de la granja de servidores

En las siguientes secciones se describen las características de la granja de servidores de prueba:

• Conjunto de datos

• Carga de trabajo

• Hardware, configuración y topología

Conjunto de datos

Para obtener pruebas comparativas, la mayoría de las pruebas se ejecutaron en un sitio de grupo predeterminado de una sola colección de sitios de la granja. Las pruebas de inicio manual iniciaron flujos de trabajo mediante una lista con 8.000 elementos.

Carga de trabajo

Las pruebas para este escenario ayudan a desarrollar estimaciones de cómo responden las diferentes configuraciones de granjas de servidores a los cambios en las siguientes variables:

• Efecto del número de servidores front-end en el rendimiento para iniciar manualmente los flujos de trabajo declarativos en varios equipos

• Efecto del número de servidores front-end en el rendimiento para iniciar automáticamente los flujos de trabajo declarativos en varios equipos

• Efecto del número de servidores front-end en el rendimiento para completar tareas en varios equipos

Las cifras de capacidad y rendimiento específicas presentadas en este artículo serán diferentes de las cifras en entornos reales. Las cifras que se presentan están diseñadas para proporcionar un punto de partida para el diseño de un entorno a una escala adecuada. Después de completar el diseño inicial del sistema, pruebe la configuración para determinar si admitirá los factores del entorno.

En esta sección se definen los escenarios de prueba y se describe el proceso de prueba que se usó para cada escenario. En cada sección de resultados de las pruebas, más adelante en este artículo, se proporciona información detallada, como los resultados de las pruebas y parámetros específicos.

Nombre de la prueba	Descripción de la prueba
Rendimiento para iniciar flujos de trabajo manualmente	Asocie el flujo de trabajo de aprobación de MOSS incluido a una lista que cree una tarea. Rellene la lista con elementos de lista. Llame al método de servicio web StartWorkflow en Workflow.asmx con los elementos de la lista durante cinco minutos. Calcule el rendimiento observando el número de flujos de trabajo en curso.
Rendimiento para iniciar flujos de trabajo automáticamente cuando se crea un elemento	Asocie el flujo de trabajo de aprobación de MOSS incluido a una lista que crea una tarea, establecida para iniciarse automáticamente cuando se crea un elemento. Cree elementos en la lista durante cinco minutos. Calcule el rendimiento observando el número de flujos de trabajo en curso.
Rendimiento para completar tareas de flujo de trabajo	Asocie el flujo de trabajo de aprobación de MOSS incluido a una lista que crea una tarea, establecida para iniciarse automáticamente cuando se crea un elemento. Cree elementos en la lista. Llame al método del servicio web AlterToDo Web en Workflows.asmx con los elementos de la lista de tareas creada por los flujos de trabajo que se iniciaron. Calcule el rendimiento observando el número de flujos de trabajo completados.

Hardware, configuración y topología

Las topologías que se usaron para estas pruebas usan un solo equipo para la base de datos de contenido y de uno a cuatro equipos front-end que tienen la instalación predeterminada para SharePoint Server 2010. Aunque los flujos de trabajo que se usaron en estas pruebas no están disponibles en Microsoft SharePoint Foundation 2010, se pueden usar los resultados para calcular escenarios similares en esas implementaciones. El conjunto de datos que se usó para estas pruebas contiene una sola colección de sitios con un solo sitio basado en la plantilla de sitio de grupo en una sola base de datos de contenido.

Para proporcionar un alto nivel de detalle en los resultados de la prueba, se usaron varias configuraciones de granja de servidores en las pruebas. Las configuraciones de granja de servidores variaron entre uno y cuatro servidores web y un solo equipo que ejecuta Microsoft SQL Server 2008. Las pruebas se realizaron con un equipo cliente. El servidor de bases de datos y todos los servidores web eran de 64 bits y el equipo cliente de 32 bits.

En la tabla siguiente se enumera el hardware específico usado para realizar las pruebas.

	Servidor web	Servidor de bases de datos
Procesador	2px4c a 2,33 GHz	4px4c a 2,4 GHz
RAM	4 GB	16 GB
Sistema operativo	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64
Almacenamiento	680 GB	4,2 terabytes
Número de adaptadores de red	2	2
Velocidad del adaptador de red	1 gigabit	1 gigabit
Autenticación	NTLM	NTLM
Versión de software	4747	SQL Server 2008 R1
Número de instancias de SQL Server	1	1
Tipo de equilibrador de carga	Sin equilibrador de carga	Sin equilibrador de carga
Nivel de registro de ULS	Medio	Medio

Topología de planeamiento de capacidad de flujos de trabajo

Resultados de las pruebas

En las siguientes tablas se muestran los resultados de las pruebas para flujos de trabajo en SharePoint Server 2010. Para cada grupo de pruebas, solo se cambian ciertas variables específicas para mostrar el efecto progresivo en el rendimiento de la granja de servidores.

Todas las pruebas que se muestran en este artículo se llevaron a cabo sin tiempo de reflexión, un retraso natural entre las operaciones consecutivas. En un entorno real, cada operación va seguida de un retraso mientras el usuario realiza el siguiente paso en la tarea. Por el contrario, en la prueba, cada operación iba seguida inmediatamente de la operación siguiente, lo que dio como resultado una carga continua en la granja de servidores. Esta carga puede causar la contención de la base de datos y otros factores que podrían afectar negativamente al rendimiento.

Efecto de escalar el servidor web en el rendimiento

Las siguientes pruebas de rendimiento se ejecutaron mediante el flujo de trabajo de aprobación que se incluye en SharePoint Server 2010. La asociación de flujo de trabajo asigna una tarea y todas las instancias se ejecutan en una sola lista. Cada instancia de este flujo de trabajo crea lo siguiente en la base de datos de contenido:

• Una entrada en la tabla de flujos de trabajo para almacenar el estado de flujo de trabajo

• Cinco elementos de la lista secundaria (una tarea y cuatro elementos del historial)

• Cuatro receptores de eventos para controlar eventos en la tarea y el elemento primario del flujo de trabajo

El umbral de posposición de flujo de trabajo se estableció en un tamaño muy grande para que las operaciones del flujo de trabajo nunca se pongan en cola. Cada prueba se ejecutó cinco veces y cada prueba se ejecutó durante cinco minutos.

Rendimiento de inicio manual

La prueba de la siguiente tabla muestra la forma en que la adición de servidores front-end afecta al rendimiento en el inicio de flujos de trabajo de forma sincrónica mediante el servicio web. Esta prueba se ejecutó con una carga de 25 usuarios simultáneos llamando continuamente al método StartWorkflow en Workflow.asmx y sin ninguna otra carga en la granja de servidores. La carga de usuarios era la carga óptima antes de que se produjeran las solicitudes web eliminadas. La lista viene rellenada con hasta 8.000 elementos.

Topología	Máximo de RPS de flujos de trabajo de aprobación
1x1	14,35
2x1	24,08
3x1	29,7
4x1	30,77

El siguiente gráfico muestra cómo cambia el rendimiento. La adición de servidores front-end no afecta necesariamente al rendimiento de la granja de servidores de forma lineal, sino que alcanza el máximo en alrededor de tres a cuatro servidores front-end. En resumen, el rendimiento máximo para iniciar manualmente flujos de trabajo es de aproximadamente 30 flujos de trabajo por segundo, y la adición de más de cuatro servidores front-end probablemente tenga un efecto insignificante.

Rendimiento de inicio manual

Rendimiento en el inicio automático de flujos de trabajo cuando se crean elementos

La prueba de la siguiente tabla muestra la forma en que la adición de servidores front-end afecta al rendimiento en el inicio automático de flujos de trabajo cuando se crean elementos. Esta prueba se ejecutó con una carga de 150 usuarios simultáneos llamando continuamente al servicio web de la lista para crear nuevos elementos de lista en una sola lista y sin ninguna otra operación en el servidor. La lista se inició como una lista vacía.

Topología	Máximo de RPS de flujos de trabajo de aprobación
1x1	13,0
2x1	25,11
3x1	32,11
4x1	32,18

El siguiente gráfico muestra cómo cambia el rendimiento. El rendimiento se acerca mucho a las operaciones de inicio manual. Al igual que la prueba de inicio manual, el rendimiento alcanza el máximo en aproximadamente tres o cuatro servidores front-end en aproximadamente 32 flujos de trabajo por segundo como máximo. La adición de tres o cuatro servidores front-end tendrá un efecto insignificante.

Rendimiento de flujo de trabajo de inicio automático

Rendimiento de finalización de tareas

La prueba en la siguiente tabla muestra la forma en que la adición de servidores front-end afecta al rendimiento de completar tareas de flujo de trabajo. La lista de tareas que los flujos de trabajo de inicio automático usaron en la prueba anterior es la lista que se usó para completar las tareas. Esta prueba se ejecutó con una carga de 25 usuarios simultáneos llamando continuamente al método AlterToDo en Workflow.asmx y sin ninguna otra operación en el servidor. La lista se inició como una lista vacía.

Topología	Máximo de RPS de flujos de trabajo de aprobación
1x1	13,5
2x1	23,86
3x1	27,06
4x1	27,14

El siguiente gráfico muestra cómo cambia el rendimiento. Al igual que la prueba de inicio manual, el rendimiento alcanza el máximo en aproximadamente tres o cuatro servidores front-end en aproximadamente 32 flujos de trabajo por segundo como máximo. La adición de más de tres servidores front-end tendrá un efecto insignificante.

Rendimiento de finalización de tareas

Efecto del tamaño de la lista y el número de instancias de flujo de trabajo en el rendimiento

La prueba de la siguiente tabla muestra cómo cambia el rendimiento a medida que el tamaño de la lista y el número de flujos de trabajo aumentan. El rellenado de datos se realizó mediante la ejecución continua de la prueba de flujo de trabajo de inicio automático hasta que se crearon un millón de elementos en la lista y mediante la detención en distintos puntos de comprobación durante toda la prueba para realizar mediciones de rendimiento, tal como se hizo con las pruebas de rendimiento principales. Se realizaron pruebas en una topología de 4x1.

Para mantener la confiabilidad durante el rellenado de datos, fue necesario mantener activada la puesta en cola de flujos de trabajo para evitar que se alcanzara el número máximo de conexiones en el servidor de bases de datos. Si no hay ninguna conexión disponible y una operación de flujo de trabajo no se puede conectar a la base de datos de contenido, la operación no podrá ejecutarse. Vea Recomendaciones para obtener más información acerca de la puesta en cola de flujos de trabajo.

Número de elementos o flujos de trabajo	Máximo de soluciones de línea base (RPS)
0	32,18
10	32
1.000	28,67
10.000	27,16
100.000	16,98
1.000.000	9,27

Rendimiento del inicio automático a medida que aumenta el número de elementos y flujos de trabajo

Para obtener una sola lista, una sola tarea y una lista de historial, el rendimiento disminuye constantemente entre 1.000 y 100.000 elementos. Sin embargo, el índice de degradación se reduce después de ese punto. La degradación del rendimiento se atribuye a diversos factores.

Un factor es el número de filas agregadas a muchas tablas en la base de datos de contenido por cada instancia. Como se mencionó anteriormente, los flujos de trabajo crean varios elementos de lista además de los receptores de eventos que cada instancia de flujo de trabajo registra. A medida que crece el tamaño de la tabla en distintos ámbitos, la adición de filas se vuelve más lenta y la disminución agregada para estas adiciones se convierte en una degradación más significativa de lo que se experimenta solo con la creación de elementos de lista.

El tamaño de la lista de tareas contribuye a una sobrecarga adicional. Al comparar el rendimiento de los flujos de trabajo que se ejecutan en listas nuevas frente a las nuevas listas de tareas, las listas de tareas tuvieron un efecto mayor en el rendimiento. Esto se debe a que las listas de tareas registran más receptores de eventos que los elementos de lista primarios. El siguiente gráfico describe las diferencias.

Rendimiento con distintas configuraciones de lista (flujos de trabajo iniciados por segundo)	Lista de tareas de un millón de elementos	Lista de tareas vacía
Lista de un millón de elementos	9,27	12
Lista de elementos vacía	9,3	13

Si sabe que tendrá que ejecutar muchos flujos de trabajo con listas grandes y necesita más rendimiento del que puede obtener según las pruebas, reflexione si las listas de tareas pueden separarse entre las asociaciones de flujo de trabajo.

Recomendaciones

En esta sección se proporcionan recomendaciones generales sobre rendimiento y capacidad. Use estas recomendaciones para determinar las características de capacidad y rendimiento de la topología inicial que creó para decidir si se debe escalar o aumentar la escala de la topología inicial.

Para obtener información específica acerca de los requisitos mínimos del sistema recomendados, vea Requisitos de hardware y software (SharePoint Server 2010).

Topologías escaladas

Se puede aumentar el rendimiento del flujo de trabajo escalando hasta cuatro servidores web. A continuación, el incremento adicional será insignificante. El rendimiento del flujo de trabajo se puede restringir mediante opciones de configuración de flujo de trabajo relacionadas con el rendimiento. Estas opciones de configuración se describen con más detalle en Puesta en cola de flujos de trabajo y configuración relacionada con el rendimiento.

Estimación de los objetivos de rendimiento

Muchos factores pueden afectar al rendimiento. Estos factores incluyen el número de usuarios y el tipo, complejidad y frecuencia de las operaciones de usuario. Los flujos de trabajo más complejos que realizan muchas operaciones con la base de datos de contenido o registran más eventos se ejecutarán más lentamente y consumirán más recursos que otros flujos de trabajo.

El flujo de trabajo utilizado en esta prueba crea varias entradas en la base de datos de contenido que se integran en las actividades de la tarea. Si espera tener flujos de trabajo con pequeños números de tareas, puede esperar características de rendimiento similares. Si la mayoría de los flujos de trabajo contienen operaciones muy ligeras, el rendimiento puede aumentar. Si los flujos de trabajo van a constar de muchas tareas u operaciones back-end intensas o potencia de procesamiento, puede esperar una disminución en el rendimiento.

Además de comprender lo que harán los flujos de trabajo, piense dónde se van a ejecutar y si se van a ejecutar con listas grandes, lo que causará que el rendimiento disminuya con el tiempo.

SharePoint Server 2010 se puede implementar y configurar de varias maneras. Como resultado, no hay una forma sencilla para calcular cuántos usuarios 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.

Puesta en cola de flujos de trabajo y configuración relacionada con el rendimiento

El flujo de trabajo usa un sistema de puesta en cola para controlar el esfuerzo relacionado con flujos de trabajo en los recursos de la granja de servidores y la base de datos de contenido. Con este sistema, cuando el número de flujos de trabajo que se ejecutan en una base de datos alcanza un umbral configurado por el administrador, las operaciones sucesivas de flujo de trabajo se agregan a la cola para que el servicio de temporizador de flujo de trabajo las ejecute. De manera predeterminada, este servicio recibe cada minuto un lote de elementos de trabajo del flujo de trabajo a través de los trabajos del temporizador.

Varias opciones de administrador de granja de servidores directa o indirectamente relacionadas con el mecanismo de puesta en cola afectan al rendimiento y escalabilidad del flujo de trabajo. En las siguientes secciones se describe lo que hacen estas opciones y cómo se ajustan para satisfacer los requisitos de rendimiento.

Descripción de la configuración básica de cola

Los administradores de la granja de servidores pueden ajustar las siguientes opciones para configurar las características básicas del sistema de puesta en cola:

• Umbral de posposición de flujo de trabajo (Set-SPFarmConfig –WorkflowPostponeThreshold <integer>)

  El número máximo de flujos de trabajo que se pueden ejecutar en una sola base de datos de contenido antes de que se pongan en cola más operaciones y solicitudes. Los flujos de trabajo en cola muestran un estado de inicio. Se trata de una configuración de toda la granja de servidores que tiene un valor predeterminado de 15. Esto representa el número de operaciones de flujo de trabajo que se procesan a la vez, no el número máximo de flujos de trabajo que pueden estar en curso. A medida que se completan las operaciones de flujo de trabajo, las operaciones sucesivas podrán ejecutarse.

• Tamaño de lote para la entrega de eventos de flujo de trabajo (Set-SPWorkflow –BatchSize <integer>)

  El servicio de temporizador de flujo de trabajo es una excepción al límite del umbral de posposición y recuperará lotes de elementos de la cola para ejecutarlos de uno en uno. Estos lotes pueden ser más grandes que el umbral de posposición. El número de elementos de trabajo que el servicio recibe por ejecución se establece mediante la propiedad BatchSize. La propiedad BatchSize se puede establecer una vez por instancia de servicio. El valor predeterminado es 100. Al ejecutarse en servidores de aplicaciones que no están configurados para ser servidores front-end, el servicio de temporizador de flujo de trabajo requiere que las opciones de configuración de flujo de trabajo en Web.config se establezcan en la base de datos de configuración. Esto debe realizarse a través de un script que llama a UpdateWorkflowConfigurationSettings() en el objeto SPWebApplication, lo que copiará la configuración de Web.config de un servidor front-end.

• Frecuencia del trabajo de temporizador del flujo de trabajo (Set-SPTimerJob job-workflow –schedule <string>)

  La frecuencia con la que se ejecuta el servicio de temporizador de flujo de trabajo se puede ajustar mediante la configuración del trabajo de temporizador. De manera predeterminada, el servicio se establece para que ejecutarse cada cinco minutos. Esto significa que puede haber un retraso de cinco minutos antes de que se procesen los elementos de trabajo en la parte superior de la cola.

  Nota

  Los elementos de trabajo programados como las expiraciones de fecha de vencimiento de tareas se aplican mediante el mismo mecanismo de temporizador. Por lo tanto, se retrasarán por el mismo intervalo de tiempo.

Se puede desactivar el servicio de temporizador de flujo de trabajo en cada servidor mediante la administración de servicios compartidos en la Administración central. De manera predeterminada, se ejecutará en todos los servidores front-end de la granja. Cada trabajo recorrerá en iteración todas las aplicaciones web y bases de datos de contenido de la granja de servidores.

La combinación del umbral de posposición, el tamaño de lote y la frecuencia del temporizador se puede usar para limitar las operaciones de flujo de trabajo en la base de datos. El rendimiento máximo se verá afectado por la rapidez con la que las operaciones se pongan en cola y se procesen en la cola.

Por ejemplo, con la configuración predeterminada, un solo servicio de temporizador y una sola base de datos de contenido, si hay 1.000 elementos en la cola, serán necesarias diez ejecuciones del trabajo de temporizador para ejecutarlos todos, lo que tardará 50 minutos en ejecutarse. Sin embargo, si establece el tamaño de lote en 1.000 y establece el trabajo de temporizador para que se ejecute cada minuto, todas las operaciones empezarán a ejecutarse después de un minuto. Si establece el umbral de posposición más alto, más operaciones se ejecutarán de forma sincrónica, lo que reducirá el número de solicitudes que se ponen en cola y el tiempo total necesario para procesar dichos flujos de trabajo.

Si no desea que los flujos de trabajo se ejecuten en servidores front-end y sabe que las operaciones no tienen que producirse inmediatamente, puede aislar el servicio de temporizador de flujo de trabajo para que se ejecute en servidores de aplicaciones selectos, establecer el umbral de posposición en un número muy bajo para forzar que los flujos de trabajo se ejecuten normalmente en el servicio de temporizador y establecer un tamaño de lote grande para que reciba elementos con mayor rapidez y frecuencia. Si desea asegurarse de que los flujos de trabajo se ejecutan de forma más sincrónica en todo el sistema, establezca un umbral de posposición más alto para que los flujos de trabajo no se pospongan a menudo y tengan un efecto más inmediato.

Modifique esta configuración para optimizar la forma en que desea que los flujos de trabajo funcionen. Se recomienda experimentar con diferentes opciones y realizar pruebas a fin de optimizarlos para los entornos y requisitos.

Ajustar la configuración para la puesta en cola

Si la granja de servidores va a mantener una carga pesada de flujo de trabajo durante largos períodos de tiempo o si se van a poner en cola muchos eventos de retraso de flujos de trabajo en el sistema, el número de operaciones de flujo de trabajo en cola crecerá. Además de la configuración de cola básica, tendrá que ajustar los valores siguientes para mantener la cola en buen estado:

• Tamaño de lote para la entrega de eventos de elementos de trabajo

  La tabla utilizada por el flujo de trabajo para eventos en la cola es una tabla de elementos de trabajo generales que se comparte con otras características que no son de flujo de trabajo en SharePoint Server 2010. Por lo tanto, hay otro trabajo de temporizador que quita de la cola los elementos de trabajo que no son de flujo de trabajo. Al igual que el tamaño de lote para la entrega de eventos de flujo de trabajo, el tamaño de lote para la entrega de eventos de elementos de trabajo especifica el número de elementos de trabajo que no son de flujo de trabajo y que se quitan de la cola a la vez.

• Frecuencia de trabajo del temporizador de conmutación por error de flujo de trabajo

  En raras ocasiones, si no se pueden entregar los eventos de flujo de trabajo a una instancia de flujo de trabajo, la entrega de eventos se programará en la cola como un elemento de trabajo de conmutación por error que se volverá a intentar posteriormente (comenzando 5 minutos más tarde, después 10 minutos si se vuelve a producir un error, después 20 minutos y así sucesivamente). Un trabajo de temporizador de conmutación por error de flujo de trabajo quita de la cola elementos de trabajo de conmutación por error, y esta configuración ajusta la frecuencia con la que se ejecutará el temporizador de conmutación por error. De manera predeterminada, esta opción se ejecuta cada 15 minutos.

• Tamaño de lote de conmutación por error de flujo de trabajo

  Al igual que la configuración de tamaño de lote de elementos de trabajo y flujo de trabajo, esta configuración controla el número de eventos de conmutación por error que cada trabajo de temporizador de conmutación por error quitará de la cola.

  Puesto que existen muchos trabajos de temporizador que operan en la misma tabla, muchos elementos en cola pueden causar contención de la base de datos y reducir el rendimiento y confiabilidad. Para reducir la contención, se recomienda lo siguiente:

  • Equilibre el umbral de posposición y tamaño de lote de flujo de trabajo de modo que el tamaño de lote sea suficientemente pequeño o la frecuencia del trabajo de temporizador suficientemente alta que un trabajo de temporizador se pueda completar antes de que inicie el siguiente trabajo de temporizador a fin de evitar que se creen demasiadas ejecuciones paralelas del trabajo de temporizador que no puedan terminar.

  • Para evitar bloqueos de tabla, no establezca ningunas de las dos configuraciones de tamaño de lote en más de 5.000.

Mejora del escalado de listas de historial y tareas

Los flujos de trabajo generan muchas tareas y elementos de historial por instancia. De manera predeterminada, estas listas están indizadas para ayudar con el escalado, pero a medida que crecen, el rendimiento disminuirá. Para reducir la tasa de disminución, mantenga separadas las listas de tareas e historial para las distintas asociaciones de flujo de trabajo y cambie periódicamente estas listas en la configuración de la asociación de flujo de trabajo, a medida que las listas se hagan grandes.

El flujo de trabajo también tiene un trabajo de temporizador diario (job-workflow-autoclean) que eliminará automáticamente las tareas e instancias de flujo de trabajo para las instancias completadas durante más de 60 días. Deje este trabajo de temporizador activo para mantener las listas de tareas y eventos en la lista de tareas lo más limpios posible. Si se deben conservar los datos, escríbalos en otras listas o ubicaciones de archivo. Este trabajo de temporizador no elimina los elementos del historial de flujo de trabajo. Si tiene que limpiarlos, debe hacerlo con un script o de forma manual a través de la interfaz de usuario de la lista.

Otras consideraciones

La eliminación de columnas en listas provoca una operación de base de datos proporcional al número de elementos en la lista. La eliminación de asociaciones de flujo de trabajo quitará la columna de estado de flujo de trabajo de la lista. Esto provoca una operación de gran tamaño en las listas grandes. Si sabe que una lista tiene millones de elementos, establezca el flujo de trabajo en No hay instancias nuevas en lugar de quitar los flujos de trabajo.

Solución de problemas

Cuellos de botella	Causa	Resolución
Contención de bases de datos (bloqueos)	Los bloqueos de la base de datos impiden que varios usuarios realicen modificaciones en conflicto en un conjunto de datos. Cuando un conjunto de datos está bloqueado por un usuario o proceso, ningún otro usuario o proceso puede modificar el mismo conjunto de datos hasta que el primer usuario o proceso se haya completado, de modo que los datos cambien y se abandone el bloqueo.	Para ayudar a reducir la incidencia de bloqueos de la base de datos, puede hacer lo siguiente: Distribuya los flujos de trabajo en más bibliotecas de documentos. Escale el servidor de bases de datos. Ajuste el disco duro del servidor de bases de datos para que sea de lectura y escritura. Existen métodos para sortear el sistema de bloqueo de la base de datos en SQL Server 2005, como el parámetro NOLOCK. Sin embargo, no se recomienda ni admite el uso de este método debido a la posibilidad de que se dañen los datos.
E/S de disco de servidor de bases de datos	Cuando el número de solicitudes de E/S en un disco duro supera la capacidad de E/S del disco, las solicitudes se pondrán en cola. Como resultado, aumentará el tiempo para completar cada solicitud.	La distribución de archivos de datos en varias unidades físicas permite E/S en paralelo. El blog sobre E/S en disco y asignación de disco en SharePoint (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0xC0A) contiene información útil sobre cómo resolver problemas de E/S en disco.
Uso de CPU del servidor web	Cuando un servidor web está sobrecargado con solicitudes de usuario, el uso de CPU promedio se aproximará al 100%. Esto impide que el servidor web responda a las solicitudes de forma rápida y puede causar tiempos de espera y mensajes de error en los equipos cliente.	Este problema se puede resolver de alguna de estas dos formas: se pueden agregar servidores web a la granja para distribuir la carga de usuarios o se puede escalar el servidor o los servidores web mediante la adición de procesadores más rápidos.

Servidores web

En la siguiente tabla se muestran los procesos y contadores de rendimiento para supervisar los servidores web en una granja de servidores.

Contador de rendimiento	Aplicar a objeto	Notas
Tiempo de procesador	Total	Muestra el porcentaje de tiempo transcurrido desde que este subproceso usó el procesador para ejecutar instrucciones.
Uso de memoria	Grupo de aplicaciones	Muestra el uso promedio de la memoria del sistema para el grupo de aplicaciones. Se debe determinar el grupo de aplicaciones correcto que se va a supervisar. La pauta básica es determinar el uso de memoria máximo para una aplicación web dada y asignar ese número más 10 al grupo de aplicaciones asociado.

Servidores de bases de datos

En la siguiente tabla se muestran los procesos y contadores de rendimiento para supervisar los servidores de bases de datos en la granja de servidores.

Contador de rendimiento	Aplicar a objeto	Notas
Promedio de longitud de la cola de disco	Disco duro que contiene SharedServices.mdf	Los valores promedio mayores que 1,5 por cilindro indican que los tiempos de escritura para ese disco duro no son suficientes.
Tiempo de procesador	Proceso de SQL Server	Los valores promedio mayores que 80% indican que la capacidad del procesador en el servidor de bases de datos no es suficiente.
Tiempo de procesador	Total	Muestra el porcentaje de tiempo transcurrido desde que este subproceso usó el procesador para ejecutar instrucciones.
Uso de memoria	Total	Muestra el uso promedio de la memoria del sistema.

See Also

Other Resources

Rendimiento y escalabilidad de flujos de trabajo en Windows SharePoint Services 3.0 (https://go.microsoft.com/fwlink/?linkid=207353&clcid=0xC0A)