lunes, 20 de abril de 2015

Tema 5 de teoría: Medir prestaciones

En este tema hemos estudiado cómo medir las prestaciones de nuestro sistema web con el objetivo de comprobar si cumplen unos mínimos requisitos de rendimiento.

La idea de hacer los tests no es exclusivamente detectar las caídas o errores de programación, sino los problemas de rendimiento y degradación de recursos, así como detectar posibles cuellos de botella e ineficiencias.

Partimos de que los tests presentan ciertas limitaciones:
  • Dificultad para hacer pruebas en un entorno de producción.
  • No se puede simular el comportamiento de los usuarios.

Según el sitio web, usaremos diferentes métricas:
  • Conexiones por segundo: Hace referencia al número de conexiones de entrada que cierto dispositivo puede manejar por segundo. También se llama transacciones por segundo o sesiones por segundo. Es un factor determinante, ya que abrir y cerrar conexiones HTTP resulta muy costoso, ya que las aperturas y cierres de conexiones consumen muchos recursos.
  • Número total de conexiones concurrentes: Métrica para determinar cuántas sesiones de usuario TCP puede manejar el balanceador al mismo tiempo. Limitado por la memoria o el procesador del dispositivo.
  • Rendimiento (en bits por segundo): Hace referencia a la velocidad a la que el balanceador maneja y pasa el tráfico. Todos los dispositivos tienen una serie de factores que acaban limitando las prestaciones, basados en la estructura interna (hardware y software). Se mide en bits por segundo. Es combinación de las variables "tamaño del paquete" y "paquetes por segundo". El paquete típico tiene un tamaño máximo (MTU, Maximun Transmitable Unit) de 1.5KB. Si hay que enviar más datos, se trocean en paquetes de este tamaño máximo.

Hemos estudiado diferentes tipo de tráfico, con características particulares y métricas más importantes al analizarlos:


Existe un límite de tráfico de red suficientemente alto que produce una degradación grave en las prestaciones. En unos casos ese límite es más fácil de alcanzar que en otros. Llegado a ese límite los tiempos de respuesta en las conexiones HTTP se degradan completamente, haciendo imposible la conexión. Cuando se monitoriza el sistema, este comportamiento se ve claramente representado en gráficas de la evolución del sistema como la siguiente:


Finalmente, como vimos, necesitamos herramientas para crear cargas HTTP específicas y evaluar cómo se comportan diferentes configuraciones de nuestros sistemas. Se suelen usar benchmarks como SPECweb o WebStone para simular un número determinado de clientes.

En sistemas críticos, en lugar de usar (o desarrollar) una herramienta para generar la carga para los tests, se le puede encargar a una empresa externa especializada, como:
  • Micro Focus Intl. - Segue Software (SilkPerformer)
  • HP (LoadRunner)
  • Micro Focus Intl. - Compuware (QALoad)
  • Rational (SiteLoad)
  • Radview (WebLoad)

Se realizan diferentes tipos de pruebas a los servidores para comprobar su funcionamiento en diferentes condiciones:
  • Humo (Smoke): pruebas preliminares para comprobar que el sistema está listo para los siguientes tests.
  • Carga (Load): cargas lo más parecidas a la real. Se ejecutan en periodos cortos (1h). Para determinar los tiempos de respuesta que tendrán los usuarios.
  • Capacidad (Capacity): actividad creciente hasta detectar el punto de saturación.
  • Estrés (Stress): para analizar el efecto de aplicar de forma continuada una carga por encima de la capacidad del sistema.
  • Sobrecarga (Overload): aplicar fuertes picos de carga durante cortos periodos.
  • Estabilidad (Stability): cargas lo más similares posibles a la real, aplicadas durante 1 día o 1 semana.

Durante la ejecución de esas pruebas, se recogen mediciones que nos indiquen lo que está ocurriendo en el sistema en cada momento y cómo reacciona éste en función de la carga introducida:
  • Medidas de la calidad de servicio ofrecida por el sistema a los usuarios (estadísticas proporcionadas por la misma herramienta de simulación de carga)
  • Medidas relativas al consumo de recursos del sistema (utilizando las herramientas del sistema operativo)

Como herramientas de simulación de carga cabe destacar:
  • Apache Benchmark
  • httperf
  • OpenWebLoad
  • The Grinder
  • OpenSTA
  • Jmeter
  • siege
  • Webstone (Mindcraft)
 
Todas ellas permiten comprobar el rendimiento de cualquier servidor web (Apache, MS Internet Information Services -IIS-, nginx, Cherokee, Tomcat, lighttpd, thttpd, etc) para comprobar el rendimiento del hardware, software o de alguna modificación que le hayamos hecho.


En cuanto a los ejercicios que vamos planteando en los temas de teoría, en este tema hemos planteado los siguientes ejercicios:
  • Ejercicio 5.1: Buscar información sobre cómo calcular el número de conexiones por segundo.
  • Ejercicio 5.2: Instalar wireshark y observar cómo fluye el tráfico de red en uno de los servidores web mientras se le hacen peticiones HTTP.
  • Ejercicio 5.3: Buscar información sobre características, disponibilidad para diversos SO, etc de herramientas para monitorizar las prestaciones de un servidor.
Como ya indicamos, la entrega de los ejercicios de clase se realiza en el repositorio personal que cada cual mantenéis en github.com, en una carpeta que podéis llamar "ejercicios_de_clase".

No hay comentarios:

Publicar un comentario