Foro - Perl en Español

Hola.

Este problema lo he planteado antes. Se trata de un aplicación CGI que ejecuta recurrentemente una consulta SQL, dicha consulta está en un método de una clase. Leyendo por ahí vi un caso en que se estaba tratando de insertar muchos registros en una BBDD, pero que solo ingresaba una pequeña parte: http://www.forosdelweb.com/f12/insertando-multiples-registros-con-mysql-512695/. Aquí se le recomienda usar la función finish(), que traté de usar pero no logro superar el problema.

Aquí va el código del método del que hablo.



Adicionalmente hay que agregar que se trata de SqlServer 7.0... también por ahí he investigado que esta BBDD va acumulando las sesiones y en este caso, como se trata de un método que es llamado persistentemente, debería ser el problema. Sin embargo haciendo pruebas, no tengo claro si el problema pasa por SqlServer o por Perl.

Muchas Gracias

¿Has puesto

$|=1;

al principio del CGI?

Hablas de un cuelgue, pero no se ve nada raro en el código... ¿No será que lo que pasa, realmente, es un tiempo agotado (timeout)? ¿Sale algo en los registros (log) de actividad del servidor web?

Debes identificar qué parte es la que provoca el agotamiento del tiempo disponible. Yo veo dos: el tiempo que tarda en resolverse la consulta, y el tiempo de creación de los objetos SBMP::Empleado. Digo que sospecho que son esos, porque todo lo demás veo que no ocupa tiempo.

Muchísimas Gracias por tu respuesta.

Cuéntame para qué es $|=1;

Sí, definitivamente es timeout, lo malo de todo esto es que no me permiten mover nada en la configuración de servidor, por ejemplo el tiempo de espera del IIS.

Al hacer pruebas y comentar este trozo de código el asunto anda bien. Así es que ahí empezó la investigación en lo que ocurre dentro del método. En este sentido, lo primero que hice fue optimizar al máximo la consulta.

Puede que el asunto esté en el objeto SBMP::Empleado. Sin embargo, el código que ejecuta es super simple:



El mensaje que envía es el siguiente:


Gracias nuevamente.

El $| controla el caché de salida. Si lo pones a un valor distinto de cero, desactivas el caché, por lo que todo print() sale inmediatamente (y no cuando se llenen los buffers de salida). De esa manera, si se va generando las filas de la tabla de forma muy lenta, con este método, al menos, vamos enviando información poco a poco al usuario.

Pero aquí, el problema no es mantener la conexión con el usuario, sino que el CGI está demasiado tiempo funcionando.

Como supongo que estás en Windows, uno de los problemas de Perl en Windows es el desastroso sistema de gestión de reserva de memoria. Puede llegar a ser 4 órdenes de magnitud más lento que el mismo programa en LInux (décimas de segundos en Linux, decenas de minutos en Windows).

Además, existe el problema de que si la consulta devuelve mucha información, puede llenar la memoria RAM del servidor, y entonces, comenzar la máquina a usar la swap. Esto lo viví una vez y era desastroso ver que un trabajo que ->la misma<- máquina, en Linux, lo resolvía en menos de 3 segundos, se traducía en casi media hora de espera, en Windows.

La solución fue dividir la consulta SQL en otras pequeñas, y hacer que la operación de join()/filtrado, la hiciese el propio Perl. Primero se comprobó que había memoria suficiente para que Perl recuperase todos los registros interesantes. Y luego, ya con toda la información en memoria, filtrar los que realmente nos interesaban.

Si SQLServer tiene soporte de LIMIT, podrías hacer pruebas para recuperar solo un cierto número de peticiones, y así, medir cuánto tiempo tarda en recuperarlos.

El cuello de botella puede estar en muchos sitperfectrijilloios... el controlador ODBC, el propio motor de base de datos, el número de registros, la complejidad de la consulta (el número de join() afecta bastante), el tamaño de la memoria RAM... No creo que el cuello de botella esté en el IIS, aunque nunca lo he controlado. Y no creo que tampoco sea Perl, porque no he leído nada al respecto.

Luego, en Internet, te encuentras con recomendaciones, como ésta donde recomiendan el buen uso de los índices de las tablas, para aumentar la velocidad.

Me imaginé que el servidor de aplicación tenía algo que ver, pero, ¿por qué pasa con Perl y no con PHP, por ejemplo...? De hecho, hay una aplicación en PHP que vuela en esa máquina... Ahora, esta consulta está optimizada al máximo, y todas las que les antecede.

Bueno, muchísimas gracias por tu respuesta.
¡¡Saludos!!

La parte del programa que has publicado, en el primer mensaje, tiene dos partes claramente separadas: la de la consulta y la de la generación de la presentación a partir de la consulta.

De las dos partes, sería interesante ver en cuál se pierde más tiempo. Lo podrías saber con, simplemente, unos print() que sacarán el tiempo que ha tardado cada parte en realizarse.

Algo así: al principio del programa importamos el módulo Time::HiRes:

y ahora ya podemos tomar mediciones de tiempo, en segundos, con precisión de milisegundos.

Vamos al código, y una línea antes de la consulta, ponemos

y en el otro extremo, pintamos el tiempo que ha tardado en resolverse la consulta


Lo mismo podemos hacer para la parte de la representación. Obtendremos, en pantalla, el tiempo que tarda en ejecutarse cada parte (bueno, como esto es un CGI, habría que adaptarlo para que saliera de forma correcta en el HTML de la página generada o en los logs de actividad del servidor web. Para este último caso, usar warn() en lugar de print()).

Mirando con más calma la función, hay alguna cosa que se puede mejorar. Por ejemplo, parece que es muy distinto el código según tengamos un valor de $visualización u otro.

Lo que podemos hacer es sacar las distintas sentencias de bifurcación y crear una sola.


(Nota: que se pueda escribir, o no, la consulta SQL de esta manera, en varias líneas, depende del motor de base de datos que estemos usando).

Como ves, hemos simplificado mucho el código, dejando solo una sentencia condicional.

Por otra parte, aunque no soy nada experto en SQL, estoy sospechando que la consulta se puede simplificar en:


Y, finalmente, de la creación de los objetos SBMP::Empleado, me parece que puede simplificarse esas consultas, si obtenemos los nombres de las personas por adelantado.

O, si sabemos que hay muchas repeticiones en la obtención de esos datos, usar el módulo Memoize con esa función.

En fin, que posibilidades hay muchas. Pero si aún así, el responsable es Perl, habrá que pensar que el problema está en el controlador que dialoga con la base de datos.

Amigo, de verdad estoy muy agradecido de tu ayuda. Como se trata de una de las tantas cargas de trabajo que me asignan tuve que dejarla de lado por un tiempo. De todas formas pruebo lo antes posible.

Saludos