Todos los programadores, antes o después, necesitamos registrar lo que pasa en nuestras aplicaciones, necesitamos conocer por donde pasan nuestros programas, con qué valores han ejecutado las funciones nuestros usuarios, etc, etc... En la aplicación con la que trabajo hacemos esto con Log4j, en este post no voy a explicar que es y que deja de ser Log4j, eso lo podeis ver aquí, en este post os voy a explicar algo que he tenido que buscar estos días porque una mala configuración de Log4j puede afectar al rendimiento de la aplicación.
En mi último pase, el pase a producción que tanto os he mencionado en mis dos últimos post, lo tenía todo listo, todo listo!!! lo prometo, pero ¿qué se me olvidó?, configurar correctamente Log4j para que los mensajes en nuestro log sólo mostrase los mensajes de tipo FATAL y dejé los logs a DEBUG.... casi nada!!! esto, que se soluciona cambiando el log4j.properties, no tiene mucha más implicación, pero resulta que dejar los logs "abiertos" en el entorno de producción, afecta de manera sobresaliente al rendimiento de la aplicación. La gente de sistemas se dió cuenta del problema, modificó el fichero Log4j, reinició la aplicación y 10 min. la web estaba funcionando como siempre. No todo el mundo se dió cuenta de esta pérdida de funcionalidad, pero a las dos horas, para que veais como afecta, llegó un momento en que devolvíamos mensajes de "conecction time out". Sólo por escribir logs!!!! flipante!!!!
Lo dicho, corregimos el log4j en producción y en caliente (Gracias, gente de sistemas..... qué haría yo sin vosotros!!!!) y bueno, me didiqué a buscar como afectan los logs, como afecta Log4j a una aplicación en función de rendimiento.... sí, ya sé, ¿como es posible que un programador utilice Log4j y no haya mirado esto? pues muy sencillo, yo entré a trabajar en mi empresa, me dijeron, mira, aquí para los logs lo hacemos así, y así se ha quedado hasta hoy, vamos, que no hemos tenido necesidad de hacer más y hasta hoy no he tenido la curiosidad de saber como afecta al rendimiento Log4j.... vamos, que hasta ahora he funcionado a base de actos de fé ..." en desarrollo DEBUG, en producción FATAL" y así hemos vivido durante muuuuuuuchoooooo tiempo. En fin, que me pongo a buscar y ahí va lo que he visto:
1. Dejar el modo DEBUG sólo para desarrollo.....ajajajajajajajajaja
2. Es recomendable consultar si el nivel del log está activo con --> logger.isDebugEnabled(), logger.isInfoEnabled(), etc, etc..
3. El peso de añadir una traza dentro del programa ralentiza su ejecución entre 5 y 50 nanosegundos mínimo.
Yo creo que era este último..... me da que era este...... jajajajajaja, en serio, en el modo DEBUG, además de los logs que yo pongo, los que se muestran por IBATIS, ACEGI, etc, etc, para cada mensaje que nos llega en desarrollo imprimimos miles de mensajes y eso es lo que hace el restraso y a mayor número de peticiones un colapso en los servidores. En fin, espero que como yo, hayais descubierto algo más....Por cierto, una adelanto, el pase del otro día, excepto por esto de lo logs, perfecto!!!. Esta semana ponemos en marcha la nueva base de datos y según vaya el tema os cuento.
No hay comentarios:
Publicar un comentario