Investigación de cuellos de botella

En este tema se describe un proceso recomendado para investigar cuellos de botella.

¿Cuál es la fuente del problema?

El origen del cuello de botella podría estar relacionado con hardware o software. Cuando los recursos están infrautilizados, suele ser una indicación de un cuello de botella. Las limitaciones de hardware, configuraciones de software ineficaces o ambas causas pueden generar cuellos de botella.

La identificación de cuellos de botella es un proceso incremental por el que aliviar un cuello de botella puede dar lugar a la detección de la siguiente. La ciencia de identificar y aliviar estos cuellos de botella es el objetivo de este tema. Es posible que un sistema funcione a picos durante breves períodos de tiempo. Sin embargo, para un rendimiento sostenible, un sistema solo puede procesar tan rápido como su componente de rendimiento más lento.

Uso de un enfoque iterativo para probar

Los cuellos de botella pueden ocurrir en los puntos finales (entrada/salida) del sistema o en el medio (orquestación o base de datos). Una vez aislado el cuello de botella, use un enfoque estructurado para identificar el origen. Una vez que se haya reducido el cuello de botella, es importante medir de nuevo el rendimiento para asegurarse de que no se ha introducido un nuevo cuello de botella en otro lugar del sistema.

El proceso de identificación y corrección de cuellos de botella debe realizarse de forma iterativa. Variar solo un parámetro a la vez, repetir exactamente los mismos pasos durante cada ejecución de prueba y, a continuación, medir el rendimiento para comprobar el impacto de la modificación única. Variar más de un parámetro a la vez podría ocultar el efecto del cambio.

Por ejemplo, cambiar el parámetro 1 podría mejorar el rendimiento. Sin embargo, cambiar el parámetro 2 junto con el cambio del parámetro 1 podría tener un efecto perjudicial y negar las ventajas de cambiar el parámetro 1. Esto conduce a un efecto neto cero y da como resultado un falso negativo en el efecto de un parámetro variable 1 y un falso positivo en el efecto del parámetro 2 variable.

Comprobación de la coherencia

La medición de las características de rendimiento después de cambiar la configuración debe realizarse para validar el efecto del cambio.

• Hardware- Use hardware coherente porque variar el hardware puede provocar un comportamiento incoherente y producir resultados engañosos. Por ejemplo, no usaría un portátil para probar el rendimiento de una solución de BizTalk.

• Duración de la ejecución de pruebas: Mida el rendimiento durante un período mínimo fijo para garantizar que los resultados sean sostenibles. La ejecución de pruebas durante períodos más largos también garantiza que el sistema haya pasado por el período inicial de preparación o rampa, en el que se cargan todas las memorias caché, las tablas de base de datos han alcanzado los valores esperados y el control de velocidad tiene tiempo suficiente para regular el flujo de datos una vez alcanzados los umbrales predefinidos. Este enfoque ayudará a detectar un rendimiento sostenible óptimo.

• Parámetros de prueba: No cambie los parámetros de prueba entre ejecuciones de prueba. Por ejemplo, los distintos tamaños de documento o complejidad de mapa pueden generar diferentes resultados de rendimiento y latencia.

• Estado limpio: Una vez completada una prueba, asegúrese de que el estado del entorno de prueba esté limpio antes de ejecutar la prueba siguiente. Por ejemplo, los datos históricos pueden acumularse en la base de datos, afectando al rendimiento durante la ejecución. El reciclaje de las instancias de servicio ayuda a liberar recursos almacenados en caché, como memoria, conexiones de base de datos y subprocesos. En el entorno de prueba, es posible que desee crear y ejecutar el procedimiento almacenado bts_CleanupMsgbox tal y como se describe en Cómo purgar manualmente los datos de la base de datos de cuadro de mensajes en un entorno de prueba (https://go.microsoft.com/fwlink/?LinkId=158064). Este script está pensado para devolver el entorno de prueba de BizTalk Server a un estado nuevo con respecto al cuadro de mensaje entre ejecuciones. El script elimina todas las instancias en ejecución y toda la información sobre esas instancias, incluidos el estado, los mensajes y las suscripciones, pero deja todas las suscripciones de activación para que no tenga que volver a inscribir las orquestaciones o enviar puertos. Tenga en cuenta que esta herramienta no se admite en sistemas de producción.

• Pruebas de rendimiento y ajuste: El objetivo de esta categoría de prueba es maximizar el rendimiento y el rendimiento de la aplicación y encontrar el rendimiento máximo sostenible (MST) del sistema. Para obtener más información sobre el planeamiento y la medición del rendimiento sostenible máximo, vea Planning for Sustained Performance (https://go.microsoft.com/fwlink/?LinkId=158065) and What Is Sustainable Performance?( ¿Qué es el rendimiento sostenible? (https://go.microsoft.com/fwlink/?LinkId=132304).

  MST es la carga más alta del tráfico de mensajes que un sistema puede controlar indefinidamente en un entorno de producción. Todas las aplicaciones de BizTalk deben probarse para evaluar su rendimiento y capacidad de procesamiento antes de pasar a producción. Como mínimo, debe ejecutar un conjunto representativo de casos de prueba que representen los escenarios de uso más comunes. Se recomienda probar las cargas esperadas y las cargas máximas en un entorno independiente que coincida con las características del entorno de producción. Este entorno debe tener instalados y en ejecución todos los servicios estándar corporativos, como los agentes de supervisión y el software antivirus.

• También se recomienda probar nuevas aplicaciones de BizTalk en el mismo hardware en producción junto con las otras aplicaciones de BizTalk que se ejecutan. Estas otras aplicaciones de BizTalk ponen carga adicional en BizTalk Server, SQL Server, E/S de red y E/S de disco. Además, una aplicación de BizTalk podría provocar que otra se regule (cuando la profundidad del espacio de almacenamiento sea demasiado grande, por ejemplo). Todas las aplicaciones de BizTalk deben ser sometidas a pruebas de rendimiento y estrés antes de entrar en producción. Además, debe determinar cuánto tiempo tarda el sistema en recuperarse de las cargas máximas. Si el sistema no se recupera completamente de una carga máxima antes de que se produzca la siguiente carga máxima, tiene un problema. El sistema se quedará cada vez más rezagado y nunca podrá recuperarse por completo.

Expectativas: rendimiento frente a latencia

Puede esperar una cierta cantidad de rendimiento o latencia del sistema implementado. Al intentar lograr un alto rendimiento y una baja latencia simultáneamente se colocan demandas opuestas en el sistema. Puede esperar un rendimiento óptimo con una latencia razonable. A medida que mejora el rendimiento, aumenta el estrés (por ejemplo, mayor consumo de CPU, contención de E/S de disco, presión de memoria y mayor contención de bloqueo) en el sistema. Esta situación puede tener un impacto negativo en la latencia. Para detectar una capacidad óptima de un sistema, se recomienda identificar y minimizar los cuellos de botella.

Las instancias completadas que residen en la base de datos pueden provocar cuellos de botella. Cuando se producen cuellos de botella, el rendimiento puede degradarse. Dar al sistema tiempo suficiente para purgar puede ayudar a solucionar el problema. Descubrir la causa de la acumulación del trabajo pendiente y ayudar a corregir el problema es importante.

Para detectar la causa del trabajo pendiente, puede analizar los datos históricos y supervisar los contadores de rendimiento (para detectar patrones de uso y diagnosticar el origen del trabajo pendiente). Normalmente, los trabajos pendientes pueden producirse cuando se procesan grandes volúmenes de datos de forma por lotes de forma nocturna. Es posible que le resulte útil detectar la capacidad del sistema y su capacidad de recuperarse de un trabajo pendiente. Esta información puede ayudarle a calcular los requisitos de hardware para controlar escenarios de overdrive y la cantidad de espacio de búfer para acomodar dentro de un sistema para controlar picos imprevistos en el rendimiento.

La supervisión de contadores de rendimiento puede ayudar a identificar posibles cuellos de botella que podrían surgir durante la ejecución. Sin embargo, cuando sospechamos que el culpable del cuello de botella de CPU o memoria puede ser uno de los componentes personalizados de la solución, se recomienda encarecidamente usar herramientas de generación de perfiles como Visual Studio Profiler o ANTS Performance Profiler durante una prueba de rendimiento para restringir e individualizar con certeza la clase que genera el problema. Obviamente, la generación de perfiles de una aplicación interfiere con el rendimiento. Por lo tanto, estas pruebas deben centrarse en la individuación de los componentes que provocan el consumo de memoria, el uso de CPU o la latencia y las cifras recopiladas durante estas pruebas deben descartarse.

La optimización del sistema para lograr un rendimiento sostenible óptimo requiere una comprensión detallada de la aplicación implementada, los puntos fuertes y débiles del sistema y los patrones de uso del escenario específico. La única manera de detectar cuellos de botella y predecir un rendimiento sostenible óptimo con certeza es mediante pruebas exhaustivas en una topología que coincida estrechamente con lo que se usará en producción. Al ejecutar pruebas de carga y estrés en un caso de uso determinado, aislar los artefactos individuales (ubicaciones de recepción, puertos de envío, orquestaciones) en instancias de host independientes y establecer los contadores correctos dentro de la herramienta de supervisión de rendimiento es fundamental para identificar la causa de un cuello de botella.

Otros temas de esta sección le guían a través del proceso de definición de esa topología y proporcionan instrucciones sobre cómo reducir y evitar cuellos de botella.

Ampliación

Los cuellos de botella pueden producirse en varias fases de una topología implementada. Algunos cuellos de botella se pueden solucionar ya sea mediante el escalado vertical o el escalado horizontal del entorno. La ampliación es el proceso de actualización del ordenador existente. Por ejemplo, puede actualizar un equipo de BizTalk Server desde un equipo de cuatro procesadores a un equipo de ocho procesadores, así como sustituir las CPU existentes y agregar más RAM. De este modo, puede acelerar tareas que consumen muchos recursos, como el análisis y la asignación de documentos. El escalado horizontal es el proceso de agregar servidores a tu implementación. La decisión de escalar vertical u horizontalmente depende del tipo de cuello de botella y de la aplicación que se está configurando. Una aplicación debe compilarse desde cero para poder aprovechar el escalado vertical o horizontal. En la siguiente guía se explica cómo cambiar las topologías de implementación de hardware basadas en cuellos de botella detectados.

El escalado vertical significa ejecutar una solución de BizTalk en hardware actualizado (por ejemplo, agregar cpu y memoria). Debe examinar el escalado vertical cuando el escalado horizontal 1) es demasiado caro o 2) el escalado horizontal no ayudará a resolver un cuello de botella. Por ejemplo, puede reducir significativamente el tiempo invertido en transformar y procesar un mensaje grande si ejecuta la tarea en una máquina más rápida.

El escalado horizontal de la plataforma de aplicaciones consiste en agregar nodos de BizTalk al grupo de BizTalk Server y usarlos para ejecutar una o varias partes de la solución. Debe considerar el escalado horizontal cuando 1) necesite aislar los hosts de envío, recepción, procesamiento o seguimiento, o bien 2) cuando los recursos de memoria, E/S o E/S de red estén al máximo para un único servidor. La carga se puede distribuir entre varios servidores; sin embargo, agregar nuevos nodos al grupo de BizTalk Server puede aumentar la contención de bloqueo en la base de datos MessageBox.

¿Entonces debería escalar verticalmente o escalar horizontalmente? El escalado de la plataforma puede reducir la latencia de una solución de BizTalk ya que hace que las tareas individuales (por ejemplo, la asignación de mensajes) se ejecuten más rápidamente. El escalado puede mejorar el máximo rendimiento sostenible y la escalabilidad de la solución de BizTalk, ya que permite distribuir la carga de trabajo a través de varias máquinas.

Véase también

Búsqueda y eliminación de cuellos de botella