¿Es log4net mucho más lento que System.Diagnostics.Trace?

Question

Estoy investigando las diferencias entre el uso de log4net y System.Diagnostics.Trace para el registro, y siento curiosidad por las diferencias de rendimiento que he observado.

Creé una aplicación de prueba para comparar el rendimiento de ambos métodos de registro en varios escenarios, y estoy descubriendo que log4net es significativamente más lento que la clase Trace . Por ejemplo, en un escenario donde registro 1,000 mensajes sin formato de cadena, el tiempo de ejecución promedio de log4net en 1,000 intentos es de 9.00ms. Trace se ejecuta con una media de 1.13ms. Muchos de mis casos de prueba tienen una variación relativamente grande en los tiempos de ejecución de log4net; La naturaleza periódica de ejecuciones largas atípicas parece sugerir interferencia de GC. Hurgando con CLR Profiler confirma que hay una gran cantidad de colecciones para una tonelada de objetos log4net.Core.LoggingEvent que se generan (para ser justos, parece que Trace genera una tonelada de objetos Char [] también, pero no muestra la gran variación que log4net hace.)

Una cosa que tengo en cuenta aquí es que aunque log4net parece aproximadamente 9 veces más lento que Trace , la diferencia es de 8 ms en 1.000 iteraciones; Esto no es exactamente un drenaje de rendimiento significativo. Aún así, algunos de mis casos de uso esperados podrían ser métodos de llamada que registran cientos de miles de veces, y estos números son de mi máquina rápida. En una máquina más lenta, más típica de las configuraciones de nuestros usuarios, la diferencia es de 170 ms a 11 ms, lo que es un poco más alarmante.

¿Este rendimiento es típico de log4net, o hay algunos errores que pueden aumentar significativamente el rendimiento de log4net?

( NOTA: soy consciente de que el formato de cadena puede alterar el tiempo de ejecución; estoy tratando de comparar manzanas con manzanas y tengo casos de prueba sin formato y casos de prueba con formato; log4net permanece proporcionalmente lento si la cadena Se usa o no el formato. )

La historia hasta ahora:

• Robert Gould tiene la mejor respuesta a la pregunta; Tenía curiosidad sobre todo si era típico ver a log4net realizar mucho más lento que la clase Trace .
• La respuesta de Alex Shnayder es información interesante, pero realmente no está incluida en el alcance de la pregunta. La mitad de la intención de introducir este registro es ayudar a depurar problemas lógicos y de rendimiento en sistemas en vivo; nuestros clientes ponen nuestros productos en muchos escenarios exóticos que a menudo son difíciles de reproducir sin configuraciones de hardware caras y a gran escala. Mi principal preocupación es que una gran diferencia de tiempo entre " no logging " y " registro " Podría afectar al sistema de tal manera que no ocurran errores. Al final, la escala de la disminución del rendimiento es grande, pero la magnitud es pequeña, así que espero que no sea un problema.

Answer 1

sí, log4xxx es más lento que el rastreo, ya que el rastreo normalmente es una herramienta cercana al kernel, mientras que log4xxx es una herramienta mucho más poderosa. Personalmente prefiero log4xxx debido a su fexibilidad, pero si desea algo que no tenga un gran impacto y realmente no necesite registros para la producción, digamos que en la depuración solo el rastreo debería ser suficiente.

Nota: uso log4xxx porque exactamente lo mismo se aplica a todos los idiomas con una biblioteca log4, no solo .Net

Answer 2

puede estar interesado en la biblioteca de Common.Logging . Es un contenedor de abstracción delgada sobre las implementaciones de registro existentes y le permite conectar cualquier marco de registro que desee en el tiempo de ejecución. También es mucho más rápido que System.Diagnostics.Trace como se describe en mi publicación de blog sobre rendimiento .

hth, Erich

Answer 3

Desde mi experiencia, el rendimiento de log4net no es un problema en la mayoría de los casos. La verdadera pregunta es, ¿por qué necesitaría " registrar las cosas cientos de miles de veces " en un sistema de producción.
Como lo veo, en producción, debe registrar solo el mínimo (la información puede ser de nivel de advertencia), y solo si es necesario (depurar un problema en el sitio) debe activar la depuración en el nivel de depuración.

Answer 4

Si desea lo mejor de ambos mundos, log4net también le permitirá iniciar sesión en el rastreador de aspnet. Activo esta opción cuando quiero obtener estadísticas de rendimiento vinculadas a eventos específicos en mi registro.

Answer 5

Acabo de ejecutar una prueba que compara la escritura secuencial con un archivo simple en comparación con el uso de Log4Net para la misma tarea. Log4Net es 400 veces más lento en comparación con un StreamWriter. archivos de registro . Pero me parece muy útil para pequeñas cantidades de entradas de registro y depuración.

Tal vez una solución para aislar el registro en un subproceso separado en algunos casos.