Gracias a una entrada en el foro de Velneo y un comentario de @emanueltoro, me he animado a escribir algo que puede parecer curioso y que, sin embargo, es el día a día de los equipos de soporte, testeo y desarrollo de software.
La entrada del foro titulada V.7.8.0: Muuucho más lento en las búsquedas se iniciaba con el siguiente comentario de Miguel:
Hola a todos,
Estoy probando la nueva versión de Velneo. Una misma búsqqueda lanzada en tercer plano en la nube, sobre una tabla de 3000 clientes y mostrada sobre una rejilla sin más historia, con la versión anterior me tardaba alrededor de 5-7 sg. Con la 7.8 se va hasta los 25 Sg!!!!!!!.
A partir de ese momento, en Velneo, comenzamos a buscar el problema y este es un resumen de las cuestiones que aparecían durante la investigación de la incidencia y que eran incógnitas a despejar hasta llegar a la conclusión final. Al lado de las pregunta que nos surgían incluyo la respuesta que se producía tras la realización de múltiples pruebas.
¿Es un problema de lentitud de las búsquedas? No, no está relacionado con las búsquedas.
¿Es un problema de los servidores de la nube? No, también sucede en local.
¡Estupendo los dos aspectos explicados del problema se habían desvanecido!
¿Se puede reproducir siempre? En mi caso sí
¿Le pasa a todos los usuarios? No, a unos sí y a otros no… ¡Espera! a los que no les pasa… alguna vez de forma extraña sí les pasa.
¿Tiene relación con el equipo? Aparentemente no, a mi en el mismo ordenador, en Mac me funciona bien y en una máquina virtual con Windows 7 me falla. Uhm… que raro
¿Tiene relación con el sistema operativo? Parece que sí, que es Windows, pero no…, pasa tanto en Windows, como en Linux.
¿Será un problema con las librerías de Qt que ejecuta cada ordenador? No, se ha comprobado que el nº de librería es el mismo tanto en la instalación como en ejecución.
¿Pasa también con la versión 7.7.2 instalado en la misma máquina que la 7.8? No, en el mismo ordenador y el mismo sistema operativo con la versión 7.8 falla y con la 7.7.2 funciona bien.
¿Pasa sólo con rejillas? Sí, probando otros objetos funcionan bien.
¿Qué ha cambiado en las rejillas? Hay una mejora en el refresco del pie de rejilla.
¿Puede tener relación? Aparentemente no, pero sí que la tiene, ya hemos localizado el problema en ese punto.
¡Eureka! Hemos encontrado el problema, sabemos donde está y ahora vamos a ver si encaja con todas las pruebas realizadas…
Todo esto que cuento hay que acotarlo entre la aparición del post en el foro, y la mañana siguiente, con conversaciones constantes con unos pocos suscriptores que sufren el problema, ya que otros no lo reproducen. Miguel y Héctor colaboraron en primera persona de forma directa con soporte. Gracias Miguel y Héctor.
Una vez localizado se ve que la mejora realizada en el refresco funciona bien. ¿Cómo? Sí el cambio es funcionalmente correcto ¿Entonces? Lo que ocurre es que genera un hilo adicional al primer plano y al hilo de carga de los registros por lo que en ese momento hay 3 hilos en ejecución ¿Y?…
Que pasa en el equipo donde siempre se reproducía el fallo ¿Cuántos núcleos tiene tu procesador? 2
Estupendo, cuando ejecutamos en Mac funciona.
Pero en una máquina virtual con Windows 7 falla.
¿Sabías que esa máquina virtual consume uno de los núcleos y que sólo deja a disposición de las aplicaciones el otro núcleo? Pues vaya.
Ahora que sabemos lo del hilo está claro, cómo sólo hay 1 core y ya está el hilo de carga de la rejilla funcionando, hasta que no finaliza ese hilo no puede ejecutarse el de refresco y, claro eso hace que no se pinten los primeros registros de la rejilla hasta que ha terminado la carga completa de todos los datos.
Y por qué a los que no usan máquina virtual y tienen un procesador con más de un núcleo, en algunas ocasiones les falla? Pues porque haciendo pruebas, llegaban a tener dos vClient en ejecución y conseguían el mismo efecto que si sólo hubiese un núcleo.
Conclusión, el testeo del software es una actividad muy compleja, la casuística es muy variada, si añadimos la dificultad de la multiplataforma, la complejidad se multiplica, y si incluimos el uso de máquinas virtuales aún más.
Por eso emanueltoro, te doy las gracias porque con la frase que ponías en tu comentario “éstos pequeños grandes errores que surgen cada vez que aparece una nueva versión” me has animado a contaros algo que acaba de suceder ayer y que creo que ayudará a entender la complicada labor que en ocasiones hay que realizar para resolver una incidencia que a priori puede parecer un fallo absurdo que nunca debió pasar desapercibido a los betatesters antes de lanzar la versión.
Es curioso como vemos las cosas cuando nosotros estamos en la posicion de programador, de cara a nuestros clientes, o cuando estamos en la posicion de clientes frente a Velneo. Me ha parecido una explicacion muy razonable, que me ha hecho entender muchas cosas y sobre todo comprender que cuando ocurre un fallo, la solución puede no ser tan rápida como queremos.
A nosotros, en nuestras aplicaciones tambien nos salen fallo, errores que parecen increibles pero ocurren y cuando sabes reproducirlos te das cuenta de que existen. Estamos en manos de una empresa extraordinaria, no es peloteo. Y perdon por lo extenso del comentario.
Un saludo. Ignacio.
Cuanta razón Ignacio, que fácil vemos la paja en el ojo ajeno y no la viga en el nuestro.
Para exigir siempre estamos muy listos, y cuanto nos cuesta ponernos en su situación, cuando en el fondo es la misma que nosotros sufrimos con nuestros desarrollos.
Nacho