Quiero escribir algunos registros en el registro de depuración que no estarán disponibles en los registros de producción que tienen nivel de registro de información. Entonces, ¿cómo afectarán estos registros de depuración adicionales al rendimiento? Quiero decir, si establecemos el nivel de registro en INFO, el registrador debe verificar cuál es el nivel de registro y encontrar que se debe ignorar log.debug.
Entonces, ¿esta verificación de nivel de registro adicional afecta el rendimiento?
¿Hay alguna forma automática de eliminar las declaraciones log.debug() durante la implementación? Quiero decir, durante el tiempo de desarrollo, log.debug estará allí y podemos depurar. Pero durante el tiempo de implementación de producción, el mecanismo automático eliminará todos los mensajes log.debug(). No estoy seguro de si esto es posible.
Entonces, ¿cómo afectarán estos registros de depuración adicionales al rendimiento?
Afecta el rendimiento de la aplicación, ya que los registradores son llamadas de E/S de disco (suponiendo que esté escribiendo en el sistema de archivos) y NO se recomienda estrictamente el nivel de registro DEBUG para entornos de producción .
¿Hay alguna forma automática de eliminar las declaraciones log.debug() durante la implementación?
No, no existe una forma mágica de eliminar las log.debug() , PERO cuando establece el nivel de registro en INFO, siempre y cuando NO esté realizando cálculos pesados mientras pasa los parámetros al método debug() , debería estar bien. Por ejemplo, si tiene el nivel de registrador establecido en INFO y asume que tiene los dos registradores siguientes en su código :
logger.debug(" Entry:: "); //this logger is fine, no calculations //Below logger, you are doing computations to print ie, calling to String methods logger.debug(" Entry : product:"+product+" dept:"+dept);//overhead toString() calls Recomiendo usar slf4j para que pueda evitar la sobrecarga de los cálculos del segundo registrador usando {} (que reemplaza con los valores reales usando su MessageFormatter ) como se muestra a continuación:
//Below logger product and dept toString() NOT invoked logger.debug(" Entry : product:{} dept{}", product, dept);Un punto más importante es que con slf4j es solo una abstracción y puede cambiar entre cualquier marco de registro , puede mirar debajo del texto tomado de aquí .
Simple Logging Facade para Java (SLF4J) sirve como fachada simple o abstracción para varios marcos de registro (p. ej., java.util.logging, logback, log4j), lo que permite al usuario final conectar el marco de registro deseado en el momento de la implementación.
Puede envolver sus declaraciones de "depuración" en una llamada a isDebugEnabled()
if (log.isDebugEnabled()) { log.debug("my debug statement"); } Del mismo modo, envuelva sus declaraciones de "información" en una llamada a isInfoEnabled() etc.
La idea detrás de hacer esto es que verificar si un nivel de registro está habilitado es una operación económica (costo fijo). El costo de generar el estado de cuenta que se está registrando variará según lo que esté haciendo.
Puede minimizar esto por la forma en que escribe sus declaraciones de registro. Si tú escribes
Object a = .... log.debug("I have an a: " + a); luego, independientemente del marco de registro que esté utilizando, el argumento debe evaluarse antes de que se ejecute la función de depuración. Eso significa que incluso si está en el nivel INFO , está pagando el costo de rendimiento de llamar a toString en a y construir la cadena de argumento. Si, en cambio, escribe, por ejemplo (dependiendo del formato que use su marco de registro, esto funciona en log4j y slf4j)
log.debug("I have an a: {}", a);no paga este costo, sino solo el costo del registrador que verifica si está o no en modo DEBUG; a menos que lo necesite, no paga por la evaluación del argumento.
La otra cosa que debe verificar es que está almacenando en búfer la salida (nuevamente, en slf4j, hay agregadores de almacenamiento en búfer) que minimizarán las escrituras.