Anche con slf4j, dovresti proteggere il tuo logging?

Question

Aiutami in una discussione qui .. :)

Il sito slf4j qui http://www.slf4j.org/faq.html#logging_performance indica che a causa della registrazione parametrizzata, le protezioni di registrazione non sono necessarie. Cioè invece di scrivere:

if(logger.isDebugEnabled()) { 
    logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); 
} 

si può ottenere via con:

Object entry = new SomeObject(); 
logger.debug("The entry is {}.", entry); 

è davvero questo va bene, o lo fa incorrere nella (seppur inferiore) costi di creazione della stringa statica che è passato al metodo trace ..?

Answer 1

cercherò di mettere le mie due centesimi da un'altra prospettiva

Che cosa è esattamente il vantaggio di registrazione parametrizzata?

Basta rinviare toString() invocazione e concatenazione di stringhe fino realmente necessario, che è quando si ha realmente bisogno di registrare il messaggio. Questo ottimizza le prestazioni quando quella particolare operazione di registrazione è disabilitata. Controllare source code for SLF4J se non si è sicuri.

La registrazione parametrizzata rende le protezioni inutili in tutti i casi?

No.

In quali casi sarebbero guardie di registrazione essere utile?

Quando ci sono altre potenziali operazioni costose.

Per esempio (nel caso questa particolare operazione di registrazione è disabilitata), se abbiamo nessuna guardia registrazione

logger.debug("User: {}", getUserService().getCurrentUser()); 

1. Ci sarebbe pagare il costo da obj = getUserService().getCurrentUser()
2. risparmieremmo il costo da "User name: " + obj.toString()

Se uso guardia registrazione:

if (logger.isDebugEnabled()) { 
    logger.debug("User: {}", getUserService().getCurrentUser()); 
} 

1. Vorremmo pagare il costo di logger.isDebugEnabled()
2. Ci sarebbe salvare il costo da obj = getUserService().getCurrentUser()
3. ci permetterebbe di risparmiare il costo da "User name: " + obj.toString()

Nella successiva c ase, salveremmo entrambi i costi al prezzo di controllare lo isDebugEnabled() due volte quando questa particolare operazione di registrazione è abilitata.

NOTA: questo è solo un esempio, non tentare di discutere le buone/cattive pratiche qui.

Answer 2

Si prega di non utilizzare l'istruzione if, perché ogni volta che guardo il codice come questo

if (logger.isDebug()) { 
    logger.debug("Of course it's debug {}", sadFace); 
} 

piango.

Spero che il costo di creazione della stringa statica sia così basso da risultare insignificante per il 99% degli utenti.

Answer 3

Scrivere e leggere tutti quelli if(logger.isDebugEnabled()) {} probabilmente costerà il tempo che ti risparmiano.

Ovviamente, chiamare il metodo di registrazione non è gratuito, ma lo stesso vale per la chiamata isDebugEnabled(). Quindi stai pagando di più per ogni istruzione di registro che è attiva se usi questo modello (perché il framework di registrazione controllerà il livello due volte).

Inoltre ingombra il codice.

In pratica, non ho trovato la penalità di prestazioni abbastanza grande da disturbare.

Se la registrazione è troppo lenta per te, scrivi un appender non bloccante che spinge gli eventi del registro in una coda senza pochi controlli e usa un thread in background per elaborarli.

Sfondo: gli appendici standard sono tutti sincronizzati in modo che l'accesso a un'applicazione multi-thread possa causare molte piccole pause in cui tutti i thread attendono che un messaggio di log venga scritto su un file.

Answer 4

Il problema con una dichiarazione di registrazione come questa:

logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); 

è che si farà un sacco di lavoro per concatenare i valori in un String, che viene poi mai utilizzata se la registrazione di debug è spento. In tal caso, è utile verificare se la registrazione di debug è attiva prima di eseguire questa linea. Quando sei solo di passaggio parametri:

logger.debug("The entry is {}.", entry); 

allora non inutilmente bisogno di costruire un String che non viene mai utilizzato, e il controllo non è necessario; solo passare argomenti a un metodo non ha un sovraccarico molto alto.

Si noti che se si dispone di espressioni relativamente costose per gli argomenti in un'istruzione di registrazione, potrebbe comunque essere utile controllare prima il livello di registrazione.

Answer 5

La protezione non viene utilizzata a causa della creazione della stringa.

Al contrario, viene in genere utilizzato per evitare un'espressione di argomento potenzialmente costosa, ad esempio entry[i].retrieveExtendedDebugInformation().formatNicely(). Per questo, il logback si assicura che l'argomento venga valutato solo quando il messaggio di log viene effettivamente stampato, mentre log4j valuta sempre l'argomento prima di chiamare debug().

Qui l'unico candidato è String.valueOf(entry[i]), che non è molto costoso, quindi è possibile fare una discussione che questa guardia è inutile del tutto.