java - loggers - ¿Hay una necesidad de hacer una comprobación if(log.isDebugEnabled()){...}?
log4j2 properties example (5)
Comprobé con el siguiente código realizando el control en mi código y no realizando el cheque. Curiosamente, si la comprobación se realiza en nuestro código para una instrucción de 4 log ejecutada un millón de veces, se requieren 400 ms adicionales. Estoy usando SLF4J 1.6.6. Si puede permitirse perder 400 ms por solicitud de millón, no necesita el cheque.
long startTime = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++) {
if (logger.isTraceEnabled()) {
logger.trace(request.getUserID());
logger.trace(request.getEntitlementResource().getResourceString());
logger.trace(request.getEntitlementResource().getActionString());
logger.trace(request.getContextMap());
}
}
long endTime = System.currentTimeMillis();
logger.fatal("With Check Enabled : " + (endTime - startTime) + " ms");
startTime = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++) {
logger.trace(request.getUserID());
logger.trace(request.getEntitlementResource().getResourceString());
logger.trace(request.getEntitlementResource().getActionString());
logger.trace(request.getContextMap());
}
endTime = System.currentTimeMillis();
logger.fatal("With Check Disabled : " + (endTime - startTime) + " ms");
---SALIDA---
* 2016-01-07 10: 49: 11,501 ERROR [: http-bio-8080-exec-3] [com.citi.cmb.entitlement.service.EntitlementServiceImpl] [] - Con la verificación habilitada: 661 ms
2016-01-07 10: 49: 57,141 ERROR [: http-bio-8080-exec-3] [com.citi.cmb.entitlement.service.EntitlementServiceImpl] [] - Con la verificación desactivada: 1043 ms
Esta pregunta ya tiene una respuesta aquí:
¿hay una necesidad de hacer un cheque explícito if (log.isDebugEnabled ()) {...}?
Quiero decir que he visto una publicación mencionando que log.debug ("algo") hace una llamada implícita para ver si el registro en modo de depuración ha sido habilitado, antes de que haga el registro. ¿Me falta algo o hay un paso intermedio que se debe realizar antes de utilizarlo?
¡Gracias!
log.debug("ResultSet rs is retrieved from OracleTypes");
vs
if(log.isDebugEnabled()){
log.debug("ResultSet rs is retrieved from OracleTypes");
}
Editar: Hice una reseña sobre esto: http://java.sg/whether-to-do-a-isdebugenabled-checking-before-printing-out-your-log-statement/
La declaración:
if(log.isDebugEnabled()){
Se usa solo por motivos de rendimiento. Su uso es opcional ya que el método de registro lo llama internamente.
Pero ahora usted pregunta si este control se realiza internamente, entonces, ¿por qué debería usarlo? Es muy simple: si registra algo tan simple como esto:
log.debug("ResultSet rs is retrieved from OracleTypes");
Entonces no necesita hacer ningún control. Si compone una cadena para iniciar sesión usando el operador anexar (+) de esta manera:
log.debug("[" + System.getTimeInMillis() + "] ResultSet rs is retrieved from OracleTypes");
En este caso, debe verificar si el registro está habilitado o no, porque si no lo está, incluso si el registro no está hecho, la composición de la cadena sí lo está. Y debo recordarle que el uso del operador "+" para concatenar cadenas es muy ineficiente.
La razón por la que esto se hace es por razones de rendimiento. Si comprueba esto primero, la log.debug(... no debería ser evaluada.
De hecho, es funcionalmente lo mismo.
Las versiones recientes de Logger simplifican esto, por lo que no hay mucha diferencia.
La mayor diferencia es que no tiene que crear las cosas para iniciar sesión, a veces hay muchas cadenas añadidas.
Sé que esto es viejo, pero para cualquiera que solo encuentre esto ...
Si usa SLF4J, puede evitar la llamada a isDebugEnabled (), mediante el uso del formato de mensajes.
Por ejemplo, en lugar de:
Object entry = new SomeObject();
logger.debug("The entry is " + entry + ".");
Utilizar:
Object entry = new SomeObject();
logger.debug("The entry is {}.", entry);
El formato del mensaje no se evaluará a menos que la depuración esté habilitada.
Por lo tanto, para casos simples, puede evitar isDebugEnabled ().
Pero en el caso de que la creación de uno de los parámetros sea costosa, aún desea usar isDebugEnabled () (incluso con SLF4J).
Por ejemplo:
if (logger.isDebugEnabled()) {
logger.debug("Here is the SQL: {}", sqlWrapper.buildSQL()); // assume buildSQL() is an expensive operation
}
En ese caso, no desea evaluar buildSQL () a menos que la depuración esté realmente habilitada.
Con SLF4J, hay cierto debate sobre su uso siempre frente a su uso selectivo. Realmente se reduce a preferencia personal. Es posible que desee utilizarlo en todas partes, para evitar que otro desarrollador (sin saberlo) cambie su mensaje de registro a algo más complejo / costoso en el futuro.