Foro - Perl en Español

Hola a todos:
Tengo una aplicación en la cual, una vez al mes, entran simultaneamente de 10-20 usuarios a utilizar un mismo programa y por lo que he leído, este programa se carga de 10-20 veces en memoria, abre de 10-20 veces la misma base de datos de MySQl y todo lo hace de 10-20 veces, haciendo lento el proceso.

Leyendo por allí me encontré que a través de FastCGI, puedo optimizar esto a una sola vez; como estoy usando Apache como Web Server, me encontré que hay un módulo (mod_fcgid-2.3.6) que ayuda con este tipo de problemas.

¿¿¿¿Vale la pena meterme en estas broncas para resolver esta problemática o existe alguna otra posible solución al respecto????

Si alguien ha utilizado este módulo, ¿¿¿¿me puede orientar en cómo utilizarlo????

Desafortunadamente esto funciona en el mundo de Windows.

Cualquier ayuda es bienvenida.

Gracias por anticipado.

Pero... vamos a ver...

¿A qué nivel de carga llega la máquina? ¿Se agota la memoria de la máquina cuando acceden todos a la vez (algo normal siendo Windows)? ¿Cuál es el cuello de botella: la cpu, el disco, la red, la memoria? ¿Cuánto dura, de media, el tiempo de sesión de un usuario? Durante ese tiempo, ¿cuánta información (en megabytes) debe transferirse desde el servidor al cliente? ¿Todo al principio o se mantiene constante durante toda la sesión, o hay un tráfico muy grande al principio y luego baja y al final vuelve a subir? ¿Qué tipo de tráfico es? ¿HTML, jpg, png, gif, pdf, JavaScript...? ¿Otro? ¿Se envían comprimidos los contenidos estáticos? ¿Cuántos procesos intervienen en la generación automática de las páginas? ¿Cuál es el tiempo medio de generación de los contenidos dinámicos? ¿La MySQL lleva un registro de las peticiones lentas (slow) para saber en qué base de datos está el cuello de botella? Etc, etc.

Saber todo esto es importante.

Cono ejemplo, en una empresa se quejaban de que su web iba muy lenta, y querían cambiar el servidor por otro mucho más "gordo". Mi solución fue mucho más sencilla, rápida, y barata: enseñarles que las fotos jpg, cuando salen de la cámara de fotos, ocupan más de 50 veces de lo que realmente se ve en una página web. Así que, con un pequeño curso de tratamiento de fotos, y reduciendo las fotos actuales, asunto solucionado (se multiplicó por más de 20 el tiempo de transmisión de las páginas).

Hola, creo saber a que se refiere, a mi me paso algo parecido con una aplicación vía mod_perl, con DBI no crea las conexiones persistenes, esto se soluciona usando en su lugar: Apache::DBI ,

A mi aun usando el Apache::DBI, me sigue dando problemas, pero puede ser por otras cosas, pruebalo y comentas.

Hola explorer:
Gracias por responder tan pronto; fíjate que le comenté al usuario administrador de la aplicación en cuestión, de toda la información que me tenía que dar para poder evaluar qué acción tomar y me dijo algo que me asombró de sobremanera:

"La aplicación no está tan lenta pues cada maestro, captura sus calificaciones cada mes y tarda en promedio un par de minutos por alumno, lo cual no se me hace tan lento pues son muchas materias tanto en Inglés como en Español y si estamos hablando de 25 alumnos por cada grupo, pues un maestro puede tardar cuando mucho de 50 a 60 minutos, lo cual es aceptable."

Con esta respuesta, voy a empezar a indagar qué puedo hacer ya con más calma y ver si algún módulo me puede ayudar a que el proceso sea un poco más ágil.

Para empezar voy a instalar el módulo Apache::DBI que menciona HernandoP a ver qué tal funciona.

Yo los mantendré informados.

Muchas gracias.

Es obvio que el cuello de botella son los 50 minutos que tarda el profesor en capturar esos datos.

Ahí es donde hay que mejorar la aplicación. O quizás no sea problema de la aplicación, sino que hay una causa ajena a ella.

Hace años, en un colegio, el director instaló un sistema de control de presencia, por el que los padres podían saber si sus hijos asistían a clase o no, consultando la página web del colegio. El software estaba preparado (era una herramienta prefabricada de gestión de colegios, clases, alumnos, cursos, deberes, calendario, etc.) Quienes no estaban preparados eran algunos profesores.

Anteriormente, los profesores pasaban la lista en la clase, para comprobar si algún alumno faltaba, y en ese caso, apuntar en la hoja de incidencias. Esas hojas, diariamente, las recogía el bedel al final de la jornada y las entregaba en secretaría, que, una vez a la semana, rellenaba unos libros con los nombres de los alumnos y las veces que no asistían a clase.

Vamos, todo muy "manual".

El problema era que los profesores, con la nueva aplicación, debían actualizar los datos, en el ordenador de profesores, cada día. Debían hacerlo ellos mismos, y solo había un ordenador para todos los profesores. Vamos, el fracaso estaba asegurado. De sobra es conocido el comportamiento de algunos usuarios, cuando se les dice que deben cambiar sus costumbres. Para esta gente, cualquier dificultad representa la excusa perfecta para desistir, y arrastrar a los demás en su propia podredumbre.

Al final, los profesores siguieron rellenando a mano las hojas de incidencias, y era en secretaría donde metían los datos en la aplicación. Los padres tenían la información de sus hijos, pero con bastante retraso.

El colegio tuvo suerte, porque con la ayuda de la administración regional, se dispuso de agendas electrónicas para los profesores, donde podían reportar de las faltas de clase, consultar y modificar la agenda, anotar incidencias, organizar las reuniones de los profesores, etc. La sincronización con el ordenador era mucho más rápida. Pero esta solución fue carísima (bueno, no importa: lo pagan los ciudadanos con sus impuestos). Muchos profesores se apuntaron de buena gana, al ver que esta solución sí les ahorra tiempo de forma radical.

Hoy en día, hay ordenadores en las aulas, y la gestión de las faltas de clase se realiza en el momento, pues el profesor tiene la lista de alumnos en la pantalla de su ordenador, y si uno de ellos no está, lo anota con un simple clic.

El director ya está pensando en el futuro, cuando todos los puestos de los alumnos estén equipados con un ordenador, y sea el propio ordenador el que diga si está o no el alumno (bueno, tan sencillo como ver si el ordenador está encendido o no y si ha arrancado ciertas aplicaciones y qué actividad de CPU, disco y red está haciendo).

Hola explorer/HernandoP.

Gracias por tus amplios comentarios y déjame platicarte algo:

Efectivamente 50 mins. en promedio por Maestro es mucho tiempo, y allí es donde quiero optimizar la aplicación con la instalación de algún módulo que pueda ayudar al respecto, pero también hay un problema de hardware pues su servidor está algo limitado en recursos y su red interna también tiene algunos problemitas, pero ellos no lo quieren ver así y pretenden que todo se arregle a través del software.

En fin, esto es el pan de todos los días y algún día se van a convencer de que tienen que invertir algo de plata para mejorar sus instalaciones y yo a mi vez mejorarles la aplicación.

Por cierto, HernandoP menciona que el módulo Apache::DBI pudiera ser una opción viable y me puse a leer algo de este módulo, pero creo que solo funciona para scripts desarrollados en "mod_perl" y todos mis scripts están en Perl de ActiveState. Puedo hacer algo al respecto o busco otra opción.

Gracias nuevamente.

Ponte al lado de un profesor, con un cuaderno, bolígrafo y reloj, y vas apuntando, al segundo, qué es lo que va haciendo (como si fueras un copiloto de coches de rally).

Luego, haces la suma

• Tiempo que tarda en localizar la información (incluidos los tiempos que tarda su mano en ir del teclado al ratón, y volver) (tiempo de búsqueda)
• Tiempo total que pasa escribiendo información (tiempo de introducción de datos)
• Tiempo total que está el proceso ejecutándose al 100% (tiempo de proceso)
• Tiempo que tarda el proceso en devolver el resultado (tiempo que ha esperado el usuario = tiempo de proceso + tiempo de transporte del resultado)
• ...

Así, sabes dónde se podrá mejorar.

A veces... no es necesario ser tan meticuloso, ya que con ver, por ejemplo, que usa el ratón para pasar de un campo a otro, sabes que eso se resuelve con un pequeño curso de manejo de ordenadores, para que aprendan a usar la tecla Tabulador.

Estimado explorer:

Fíjate que este primer mes de clases (Agosto), voy a hacer lo que me recomiendas y a ver qué pasa, creo que tienes razón, muchas veces algo trivial nos pone a trabajar de más y a dudar de muchas cosas.

Los mantendré al tanto, en vía de mientras les envío un gran abrazo desde Guadalajara, Mexico, la tierra del Tequila y de los próximos Juegos Panamericanos 2011.

Hasta siempre.