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”.

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