Cuellos de Botella (Bottlenecks)


En esta entrada vamos a apuntar a uno de los temas de mayor importancia en las pruebas de Performance, los Bottlenecks.

Definición

Un cuello de botella (de aquí en más lo llamaré BN) es un fenómeno donde el rendimiento o la capacidad de todo un sistema está limitado por un único componente. El termino proviene de la situación en la que, a medida que el agua se vierte de una botella, la tasa de salida está limitada por la anchura del conducto de salida – es decir, cuello de botella. Al aumentar la anchura del cuello de botella, se puede aumentar la tasa en que el agua fluye.

Un BN es una disminución de la Performance de la aplicación, no una detención de la aplicación. Si la aplicación se detiene es una falla, no un BN.

Los BN no son estáticos, al realizar actividades de configuración, tunning, y reparación implica que los BN sean altamente transitorios en locación, duración y capacidad.

El BN crítico es aquel que al removerlo mejora la performance y nos permite encontrar otros BN al ejecutar determinado workflow del usuario.

El análisis de BN y el aislamiento de los mismos pueden hacerse fácilmente cuando sistemáticamente se conoce y se entienden los conceptos fundamentales de “La teoría de la formación de colas”.

Representación grafica de un cuello de botella
Representación grafica de un cuello de botella

Como Identificarlos

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 estos cuellos de botella.

Los BN se pueden producir en extremos (entrada/salida) del sistema o en cualquier otro lugar (orquestación/base de datos). Una vez que se haya aislado la ubicación del BN, se puede llevar a cabo un enfoque estructurado para identificar el origen.

Hasta que un BN no sea solucionado, ningún otro tuning va a mejorar la Performance general de la aplicación durante determinado workflow. Antes de trabajar sobre cualquier BN, primero debe ser identificado y aislado para poder encontrar una solución más rápida. Después de que el BN es detectado debe reproducirse a medida que se va realizando el tuning, realizando siempre 1 cambio a la vez en busca de eliminar el BN.

Al analizar los resultados de los recursos utilizados por la aplicación durante la ejecución de determinado workflow de usuario se pueden tomar como un síntoma de existencia de un BN en los siguientes casos: (solo son algunos de los tantos que hay)

Síntomas en el CPU

Principalmente en la métricas Processor Utilization y Runnable Queue.

Processor Utilization: Esta métrica indica el porcentaje de uso del CPU.

  • La utilización ideal del CPU debe ser de entre 75% u 85% .
  • Si su valor es 100 por un largo periodo de tiempo existe un grave problema.
    • Esto puede significar thrashing (muy poca RAM o demasiados threads).
    • También puede significar que existe código ineficiente ya que realiza demasiada acciones sobrecargando de trabajo al CPU.
  • Si su valor es muy bajo durante un largo periodo de tiempo mientras la aplicación es utilizada posiblemente sea un problema pero muchas veces se prefiere que así sea.
    • Esto puede significar que la aplicación esta bloqueada por largos periodos de tiempo en alguna tarea de I/O (Trabajo a Disco, Red o DB).
    • También puede significar que el trabajo lo esta realizando todo otro servidor y hasta que el mismo no termine el servidor actual se queda esperando.

Runnable Queue: Esta métrica indica el promedio de procesos o hilos que están esperando que el OS les de tiempo de CPU.

  • Mientras este por encima de cero, el sistema puede mostrar contención de recursos. Comúnmente se dice que la Performance empieza a degradarse cuando el tamaño de la cola crece 4 veces mas que la cantidad de procesadores disponibles.
Síntomas en el Disco

El síntoma mas básico que se puede observar en el disco es cuando las cosas tardan más de lo debido mientras que el CPU se encuentra con una utilización aceptable. En esos casos se va a poder observar que el disco esta realizando mucho trabajo el cual debería quedar a cargo de la RAM o DB ya que el disco es el punto mas débil al realizar movimientos mecánicos.

Síntomas en el Red

Comúnmente la mayoría de los problemas se debe a razones externas a la aplicación. El ancho de banda suele ser el primer punto a verificar.

Síntomas en la Memoria

El mejor indicador para verificar la performance de la memoria es la paginación. La paginación deja espacio libre en la memoria real para que sea utilizada por otros procesos ubicando su contenido en disco (swapeando). Obviamente que si todos los procesos entran en la memoria real (no hay procesos pidiendo usar la Ram física) no va a ver necesidad de swapear.

La paginación afecta la performance de muchas maneras. Una, es que si se manda a disco un proceso que la aplicación necesita correr, el SO tiene que llevar ese proceso desde el disco hacia la memoria física, ocupando tiempo de disco y CPU para realizar la tarea. Este efecto de cascada  que involucra al disco y la CPU pueden degradar la performance de todo el sistema siendo difícil detectar en que lugar se provoca la paginación. La paginación si se usa moderadamente puede se beneficioso para la aplicación  ya que los recursos de memoria se usan eficientemente no quedando memoria real sin uso y siendo más rápida la buscada de información en la memoria real.

Para profundizar sobre el tema:

http://www.ibm.com/developerworks/rational/library/05/1004_gupta/index.html

http://www.javaperformancetuning.com

http://www.sql-server-performance.com/

http://www.linux-mag.com/id/799

7 pensamientos en “Cuellos de Botella (Bottlenecks)”

  1. José, excelente artículo. Una consulta que se me viene ya que estoy recién aprendiendo sobre el tema. ¿Necesariamente uno tiene que conocer de programación para identificar un módulo como cuello de botella?, al identificarlo.. ¿Como aborda exactamente ese módulo?, ¿Necesita soporte del lado de desarrollo para conocer exactamente la funcionalidad?.
    Y con respecto a los otros temas más de hardware.. ¿Pasa por un Tester de performance el hecho de conocer la infraestructura montada detrás del software? ¿O bien son temas que abarcarían más al área de Infraestructura, redes o como se llame?, ¿O se trabaja codo a codo en estos casos?.

    Desde ya muchas gracias por el espacio y los artículos.

    Por último, el link de la web de IBM esta caído.

    Saludos.

    Me gusta

    1. Hola Maximiliano,

      Gracias por comentar en el blog.

      ¿Necesariamente uno tiene que conocer de programación para identificar un módulo como cuello de botella?
      No, pero tenes que tener una noción de como funciona el software y un conocimiento sobre la herramientas que uses para identificar el mismo.

      ¿Como aborda exactamente ese módulo?
      En una primera instancia vas a tener un conjunto de módulos sobre los cuales se sospecha que sean los que generan el problema. Para poder probar esta hipótesis necesitas hacer profiler del código e ir investigando en profundidad que pasa en ese código y si es posible que este causando problemas de performance (acá si es necesario entender de programación y de herramientas de profiling como Jprofiler). Luego de este paso vas a tener un grupo de módulos mas reducidos y sobre los cuales trabajar.

      ¿Necesita soporte del lado de desarrollo para conocer exactamente la funcionalidad?
      Las pruebas de performance deben tener destinado su tiempo y equipo determinado, necesitas alguien que entienda la aplicación para definir los flujos, necesitas gente de IT/infra que te controle/monitoree los recursos en el ambiente de pruebas y necesitas gente de Dev que ayude a determinar que esta pasando y cual es la posible solución. No es algo que se pueda hacer en solitario.

      ¿Pasa por un Tester de performance el hecho de conocer la infraestructura montada detrás del software? ¿O bien son temas que abarcarían más al área de Infraestructura, redes o como se llame?, ¿O se trabaja codo a codo en estos casos?.
      Como detalle en la respuesta anterior, es una actividad que requiere distintos roles que se vayan complementando y compartiendo información.

      Gracias por avisar del link, ya esta reparado

      Saludos!

      José

      Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s