Errores

Como ya se habrán dado cuenta, he andado muy desconectado del blog, y para el caso también de internet. Han sido semanas pesadas en el trabajo, pero la anterior se caracterizó por una carga de trabajo moderada con una de presión bastante más grande.

Para no hacer el cuento largo, me pidieron hacer una prueba de estrés en un servidor. Pensé que la prueba en sí sería fácil (con algo como ab), pero leyendo y siguiendo el consejo del buen panda, opté por usar siege, herramienta que también es mencionada en el libro de Tomcat de O’Reilly. Leí, según yo me preparé bien, revisé varias veces las condiciones de la prueba, y en el día y la hora indicada la realicé (en realidad fueron varias).

Pensé que todo había salido bien, así que procedí a hacer el respectivo reporte… y fue donde realmente comenzó todo. Dejemos al lado que el formato del reporte no fue el que esperaban: los resultados no cuadraban. Y entre que yo soy un noob para esto de las pruebas y entre que no confiaban en que hubiera realizado la prueba correctamente, fueron 3 días para olvidar, pues terminé saliendo en promedio después de las 12 de la noche.

Entrando en detalles más técnicos, siege pide un archivo con una lista de URL a probar. El problema, y mi error, fue haber puesto URL de más, por haber entendido que se probarían N tipos de páginas y no N páginas exactamente. Pero por lo demás, las características de la prueba no estaban mal, y la forma de ejecutar la prueba tampoco. ¿Entonces?

Lo que me alegaban era que en la prueba se emulaban N número de usuarios que accederían al servidor al mismo tiempo, pero los resultados reportaban que no era así, y el número de veces que se visitaban los URL era realmente muy poco para el tiempo que duró la prueba. El panda me auxilió muchísimo con la interpretación de los resultados, y efectivamente, salió a relucir que una de las razones era por haber puesto URL de más. Error 100% mío, y en una situación laboral como la que estoy viviendo ahora, era de esperarse que me fueran a reclamar, con justa razón. Sin embargo, aun con reconocer mi error, los resultados marcaban claramente que el servidor no aguantaba mucho, pero me seguían insistiendo que la forma de hacer la prueba había estado mal, independientemente del número de páginas que había seleccionado para probar.

Después de la tormenta, se corrió una prueba emergente para comprobar que realmente había hecho la prueba original correctamente. Los resultados no mentían: se probaron menos páginas (un número cercano a las que originalmente se tenía planeado), pero se mostraba también la tendencia del servidor a no aguantar al número de usuarios indicados al mismo tiempo.

¿Qué aprendí de todo esto?

  1. Que el mundo del benchmark es mucho, pero mucho más complicado de lo que yo creía.
  2. Que aunque sé que soy humano y que obviamente me puedo equivocar, un error bajo esta situación puede costarme muy caro.
  3. Que estoy bajo mucha más presión que la que originalmente  pensaba.
  4. Que no quiero estar por siempre en una situación laboral como la actual.

Ahondando un poco en el punto 4, no tiene mucho que ver lo pesado del trabajo, o ni siquiera que no paguen las horas extra; tiene mucho más peso para mí el tiempo que le puedo dedicar a los demás, y por supuesto, a mí mismo.

Añoraba el fin de semana. Lástima que ya terminó. Tengo en puerta decisiones muy grandes, y relativamente poco tiempo para hacerlas. Como hace algunos años, necesito que los días tengan al menos 48 horas para poder hacer todo lo que debo. Mientras tanto, aquí andamos, tratando de no sucumbir ante la situación.

Agradezco muchísimo al panda por su invaluable ayuda y su tiempo en estos días, así como las palabras de aliento de varios de los mexicanos en Japón (ellos saben quienes son).