Benchmark: Diseño de pruebas


Saber cómo se va a comportar un servidor, por ejemplo, un Apache, exige someterlo a una pruebas específicas que nos den una idea de lo que es capaz. Por ejemplo, un objetivo claro es determinar el número de peticiones de servicio por segundo que nuestro servidor es capaz de soportar/atender dentro de ciertas restricciones, como no esperar (los clientes) más de X segundos (5-8 segundos es un buen valor para X) y el rendimiento no baja de 320.000 bits por segundo (SPECweb99: http://www.spec.org/osg/web99/). Conocer esta información es importante, por ejemplo, para que nuestro servicio no muera de éxito, es decir, que un crecimiento demasiado rápido del volumen de carga de una plataforma web (mantenido o con picos puntuales) pueda producir lentitud o incluso cortes en el servicio, con las consiguientes pérdidas en oportunidades de negocio e imagen.

Otro objetivo puede ser el número de conexiones simultáneas que soporta sin errores y sin enviar una petición no válida: debe generar un mensaje de respuesta. Y también, por supuesto, el rendimiento entendido como el número de bytes transmitidos por unidad de tiempo.

¿Cómo lo hacemos?

Para probar que se cumplen nuestros deseos (objetivos, por tanto, de las pruebas que tenemos que hacer), necesitaremos someter a nuestro servidor a determinadas pruebas. Ello lo haremos en un entorno controlado (es decir, no contra nuestro servidor en producción, si ya lo está) y con un sistema de prueba que:

  • Disponga de más de un cliente (si solo tenemos uno, es muy probable que los límites que probemos sean los de nuestro cliente y, si no es así, mejor que pongamos al cliente de servidor 😉 ) Generalizando, si deseamos llevar al límite a nuestro servidor, éste debe ser el cuello de botella (bottleneck) del sistema de prueba.
  • Que la red hasta el servidor a probar esté libre de tráfico que no afecte a nuestras pruebas y, al igual que con el cliente, que no sea el cuello de botella
  • Selección aleatoria de las peticiones para que el mecanismos de caché del servidor esté también probado

Además, bajo ninguna circunstancia debemos probar un servidor ejecutando los tests desde el propio servidor. ¿Por qué? Pues porque test y servicio competirán por los mismos recursos (CPU, RAM,…) y los resultados no serán válidos.

Pero ¿qué pruebas haremos?”

En esta entrada me voy a dedicar a lo más fácil: varios clientes lanzan un gran número de peticiones hacia el mismo recurso del servidor con lo que lograremos medir el rendimiento logrado. ¿Es interesante? Sí. ¿Es real? No, ya que las condiciones probadas no son las que se encontrará el servidor en funcionamiento al, en entre otros factores, no probar el sistema de caché del servidor:

httperf --server demo.eps.ua.es --uri /index.html --num-conn 5000 --num-call 10 --rate 200 --timeout 5

En estas circunstancias (5.000 conexiones con 10 peticiones por conexión, con 200 conexiones por segundo y se espera 5” para obtener la respuesta, si no llega, error), el objetivo será, básicamente, el número de peticiones de servicio por servicio capaz de atender antes de saturarse.

De los resultados que nos proporciona httperf debemos fijarnos en:

  • Conexiones: nos indicará cómo se ha comportado el servidor
  • Respuestas: nos dirá si ha sido capaz de atender todo lo que le ha llegado
  • Tiempos de respuestas: ¿manejamos tiempos aceptables para la calidad de servicio que queremos?
  • Errores: ¿cuántas peticiones se han servido por encima del timetout marcado? ¿Cuántos errores porque el sistema no admitía más?
  • Red: ¿está saturada? Si es así, debemos realizar las pruebas aumentando el ancho de banda de la red y que no sea nuestro cuello de botella.

También debemos recordar que, si esta prueba la estamos realizando desde un único cliente, quizás los límites que detecte sean del cliente y no del servidor.

httperf

Figura 1.- Salida del comando: httperf –server demo.eps.ua.es –uri /index.html –num-conn 5000 –num-call 10 –rate 200 –timeout 5

En la figura 1 esta la captura de la salida de la ejecución del comando anterior. ¿Qué podemos deducir?:

  • Acepta todas las conexiones –> Deberíamos “estresarlo” para conocer sus límites
  • Y también prácticamente todas las peticiones por segundo que le lanzamos (2.000)
  • Con buenos tiempos de respuesta
  • Sin errores y sin saturar la red

En definitiva, buenos resultados. Nuestro servicio soporta esas condiciones de trabajo.

Anuncios

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