Soy un fiel creyente en eso de que uno aprende de los errores. Cuando uno se equivoca, y le interesa lo que hace y quiere hacerlo bien, se analiza el error y las formas de evitarlo a futuro. En este post quiero compartir uno de estos aprendizajes. Nos pasó en más de un proyecto (y casi que a la vez) que la información que teníamos de la infraestructura del sistema no era correcta, entonces, al analizar los resultados de las pruebas de performance habían cosas que no cerraban, o que no entendíamos su comportamiento. Luego de mucha investigación llegábamos a que había un componente extra del que nadie nos había comentado, o que la ruta de red por la que se estaba accediendo a determinado componente no era tan directa como nos habían comentado, o como estaba plasmada en el diagrama que nos habían proporcionado.
Los dos problemas fueron bastante diferentes, pero la solución podría ser la misma: validar la infraestructura de pruebas.
Algunos ejemplos de validaciones
- Validar componentes y sus versiones: acceder a cada uno de los nodos verificando las IPs de los componentes y que cuenten con los servicios indicados. Validar los sistemas operativos, y verificar las versiones de los mismos, así como las versiones de los componentes (por ejemplo, las versiones de Java, Apache, etc.).
- Validar configuraciones iniciales: en una prueba generalmente se prueban distintas configuraciones, y en otras ocasiones algunos componentes no se tocan. Entonces, para validar que lo que se documente en los resultados sea preciso, es necesario revisar las configuraciones (al menos las más relevantes). Por ejemplo, tamaños de cada pool de conexión (por ejemplo, en el pool a la base de datos), máximo y mínimo de memoria asignada (en el caso de JVM), etc.
- Validar conexiones y rutas de red: para esto, desde cada nodo, realizar un trace route hacia los nodos con los que se conecta, para validar así los saltos de red. Hacer esto también desde las máquinas generadoras de carga.
- Validar puertos: este lo menciono en particular porque fue lo que nos hizo dar cuenta de uno de los problemas que tuvimos. Si estoy accediendo al servidor web al puerto 80 donde hay un Tomcat, revisar que el Tomcat esté configurado en el 80. Lo que nos pasó es que estaba en el 8080, y esto era porque habían colocado el Tomcat atrás de un Apache. Esto es una práctica habitual(**), pero habían omitido contarnos de esta configuración ya que “el Apache es liviano y no agrega overhead”. Eso suele ser cierto, pero no significa que no genere contención si hay algo mal configurado, como en este caso. La cantidad de conexiones que aceptaba no eran suficientes para la carga, entonces encolaba los pedidos. Nosotros estábamos intentando entender por qué JMeter nos daba ciertos resultados por un lado, mientras que en el access log del Tomcat los tiempos registrados en el time-taken eran muchísimo menores.
(**) Combinar Tomcat y Apache tiene ciertas ventajas. Debería permitir un manejo de concurrencia mayor y optimización de recursos mediante compresión y caché.
Cerrando
Claramente tuvimos cierto trabajo extra para intentar entender qué era lo que sucedía. De haber conocido la infraestructura no hubiéramos tenido estos problemas. Se podría considerar que esto es responsabilidad del cliente, quien no nos proporcionó la información adecuada y por eso nos hizo desperdiciar tiempo. Pero en vistas a futuro, con tal de dar un mejor servicio y no depender del conocimiento o transparencia de la infraestructura que haya, me parece mejor realizar ciertas validaciones antes de comenzar a realizar análisis.
Yo esto lo veo como una tarea de testing ya que al fin de cuentas lo que estamos buscando es información para reducir riesgos.
¿Hay algo más que te parezca importante agregar a esta lista?
