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 ser hardware o software relacionado. Cuando los recursos están infrautilizados, suele ser una indicación de un cuello de botella. Los cuellos de botella pueden deberse a limitaciones de hardware, por configuraciones de software ineficaces o por ambos.

La identificación de cuellos de botella es un proceso incremental, donde la solución de un cuello de botella puede llevar a descubrir otro. El objetivo de este tema consiste en encontrar el modo de identificar y solucionar estos cuellos de botella. Es posible que un sistema obtenga valores máximos durante breves períodos de tiempo. Sin embargo, para un rendimiento sostenible un sistema solo podrá procesar tan rápido como su componente de realización más lento.

Uso de un enfoque iterativo para probar

Los cuellos de botella pueden producirse en los puntos de conexión (entrada o 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. Después de facilitar 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. Varía solo un parámetro a la vez, repite exactamente los mismos pasos durante cada ejecución de prueba y, a continuación, mide el rendimiento para comprobar el impacto de la única modificación. Si se modifica más de un parámetro de una vez, podría ocultarse 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 del parámetro 1 variable y un falso positivo en el efecto del parámetro 2 variable.

Comprobación de la coherencia

Medir 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 calentamiento o rampa en el que se rellenan todas las memorias caché, las tablas de base de datos han alcanzado los recuentos esperados y la limitación tiene tiempo suficiente para regular el rendimiento una vez alcanzados los umbrales predefinidos. Este enfoque ayudará a descubrir el rendimiento óptimo sostenible.

• Parámetros de prueba: No modifique los parámetros de prueba de la ejecución de pruebas a la ejecución de pruebas. Por ejemplo, si se modifica la complejidad de asignación o el tamaño del documento, se pueden producir resultados de latencia y rendimientos distintos.

• 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 se pueden crear en la base de datos que afecta al rendimiento en tiempo de ejecución. El reciclaje de las instancias de servicio ayuda a liberar recursos almacenados en caché, como memoria, conexione 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 los puertos de envío. 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 la planeación y medición del rendimiento máximo sostenible, consulte Planning for Sustainable Performance (https://go.microsoft.com/fwlink/?LinkId=158065) and What Is Sustainable Performance? (https://go.microsoft.com/fwlink/?LinkId=132304).

  El 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 obtener rendimiento y rendimiento 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 demás aplicaciones de BizTalk que se ejecutan. Estas otras aplicaciones de BizTalk colocan carga adicional en el BizTalk Server, SQL Server, E/S de red y E/S de disco. Además, una aplicación de BizTalk podría hacer que otra limitación (cuando la profundidad de la cola sea demasiado grande, por ejemplo). Todas las aplicaciones de BizTalk deben ser de rendimiento o esfuerzo probadas 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 irá más allá y más atrás y nunca podrá recuperarse completamente.

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, un mayor consumo de CPU, mayor 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. Detectar la causa de la compilació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 descubrir 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 adaptarse dentro de un sistema para controlar picos imprevistos en el rendimiento.

La supervisión de contadores de rendimiento puede ayudar a individuar posibles cuellos de botella que podrían surgir en tiempo de ejecución. Sin embargo, cuando sospechamos que el culpable del cuello de botella de CPU o memoria puede ser uno de los componentes personalizados que componen 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 individuar 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 puntos débiles del sistema y los patrones de uso del escenario específico. El único modo de descubrir cuellos de botella y prever un rendimiento sostenible y óptimo con seguridad consiste en realizar comprobaciones exhaustivas en una topología que se aproxime a la que se usará en la producción. Al ejecutar pruebas de carga y esfuerzo en un caso de uso determinado, aislar los artefactos únicos (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 reducir 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 mediante el escalado vertical o el escalado horizontal del entorno. El escalado vertical es el proceso de actualización del equipo existente. Por ejemplo, puede actualizar un equipo BizTalk Server de un equipo de cuatro procesadores a un equipo con 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 la implementación. La decisión de escalar o reducir verticalmente 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 las instrucciones siguientes 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). Debería examinar el escalado vertical cuando el escalado horizontal es demasiado caro o 2) el escalado horizontal no ayudará a resolver un cuello de botella. Por ejemplo, puede reducir significativamente el tiempo dedicado a 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 examinar el escalado horizontal cuando 1) debe aislar el envío, la recepción, el procesamiento, los hosts de seguimiento o 2) cuando la memoria, la E/S o los recursos de E/S de red se agota 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.

¿Debería escalar verticalmente o escalar horizontalmente? El escalado vertical de la plataforma puede reducir la latencia de una solución de BizTalk porque hace que las tareas únicas (por ejemplo, la asignación de mensajes) se ejecuten más rápido. El escalado horizontal puede mejorar el máximo sostenible throughtput y la escalabilidad de la solución de BizTalk, ya que permite distribuir la carga de trabajo entre varias máquinas.

Consulte también

Búsqueda y eliminación de cuellos de botella