Pergunta

Eu sou um grande fã de log4net , mas, recentemente, alguns (no meu departamento) questionaram sua inclusão em nossos projetos por causa da aparentemente peso de cada método de registro. Eu diria que há melhores técnicas do que outros, mas isso é outra questão.

Estou curioso para saber, qual é o impacto típico de uma chamada log4net DebugFormat do tipo em suas aplicações. Vou deixar de fora variáveis ??como número de declarações de log por linhas de código, etc, porque eu estou apenas olhando para qualquer coisa que você já viu no mundo real.

E, estou ciente da técnica simples de adicionar uma cláusula de guarda para declarações de avaliação longos por exemplo:

if (log.IsDebug)
{
  log.DebugFormat(...);
}

Então, vamos excluir que a partir de consideração para agora.

Foi útil?

Solução

Eu não estou familiarizado com log4net, ou log.DebugFormat (...).

Mas o custo de exploração madeireira está realmente em duas áreas.

A primeira é a chamada de registro, eo segundo é a persistência real de informações do registo.

Os guardas ajudar a reduzir a chamada de registro para um mínimo quando o log não é realmente necessário. Ela tende a ser muito rápido, uma vez que é pouco mais do que uma chamada de método e uma comparação de duas escalares.

No entanto, quando você não usar guardas, o custo pode muito bem tornar-se o preço de criar os argumentos de registo actual.

Por exemplo, em log4j, esta foi uma expressão comum:

log.debug("Runtime error. Order #" + order.getOrderNo() + " is not posted.");

Aqui, o custo é a avaliação real da expressão de cadeia tornando a mensagem. Isso ocorre porque, independentemente do nível de log, essa expressão, ea cadeia resultante são criados. Imagine se em vez disso você tinha algo como:

log.debug("Something wrong with this list: " + longListOfData);

Isso poderia criar uma variável de cadeia grande e caro que, se o nível de log não foi definido para DEBUG, seria simplesmente desperdiçada.

Os guardas:

if (log.isDebug()) {
    log.debug(...);
}

Elimine esse problema, uma vez que a chamada isDebug é barato, especialmente em comparação com a criação real do argumento.

No meu código, eu escrevi um wrapper para o registo, e eu posso criar registros como este:

log.debug("Runtime error. Order # {0} is not posted.", order.getOrderNo());

Este é um compromisso legal. Esta se baseia em Java varargs, e os meus código verifica o nível de log e, em seguida, formata a mensagem adequadamente. Isso é quase tão rápido como os guardas, mas muito mais limpo para escrever.

Agora, log.DebugFormat pode muito bem fazer uma coisa semelhante, que eu não sei.

Além de tudo isso, é claro, é o custo real de registro (para a tela, para um arquivo, a uma tomada, etc.). Mas isso é apenas um custo você precisa aceitar. Meu melhor prática para que, quando prático, é para encaminhar as mensagens de log reais para uma fila, que é então colheram e saída para o canal adequado usando uma thread separada. Esta, pelo menos, ajuda a manter o registo fora de sintonia com a computação principal, mas tem despesas e complexidade de seu próprio.

scroll top