Estoy investigando las diferencias entre usar log4net y System.Diagnostics.Trace para el registro, y tengo curiosidad sobre las diferencias de rendimiento que he observado.¿Es log4net mucho más lento que System.Diagnostics.Trace?
Creé una aplicación de prueba para comparar el rendimiento de ambos métodos de registro en varios escenarios, y descubro que log4net es significativamente más lento que la clase Trace. Por ejemplo, en un escenario en el que registro 1,000 mensajes sin formato de cadena, el tiempo medio de ejecución 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 cantidad relativamente grande de variación en los tiempos de ejecución de log4net; la naturaleza periódica de ejecuciones largas atípicas parece sugerir la interferencia GC. Hurgar 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 estoy teniendo en cuenta aquí es que a pesar de que log4net parece aproximadamente 9 veces más lento que Trace, la diferencia es 8ms sobre 1000 iteraciones; esto no es exactamente un drenaje de rendimiento significativo. Aún así, algunos de mis casos de uso esperados pueden ser métodos de llamadas que están registrando cosas cientos de miles de veces, y estos números provienen 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 intentando comparar manzanas con manzanas y tengo casos de prueba sin formato y casos de prueba con formato; log4net se mantiene proporcionalmente lento si el formato de cadena se utiliza o no)
la historia hasta ahora:.
- Robert Gould tiene la mejor respuesta a la pregunta; Tenía curiosidad sobre todo si era típico ver que log4net funciona mucho más lento que la clase
Trace. - La respuesta de Alex Shnayder es información interesante, pero en realidad no cae dentro del alcance de la pregunta. La mitad de la intención de introducir este registro es ayudar a eliminar los problemas lógicos y de rendimiento en los sistemas en vivo; nuestros clientes colocan nuestros productos en muchos escenarios exóticos que a menudo son difíciles de reproducir sin costosas configuraciones de hardware a gran escala. Mi principal preocupación es que una gran diferencia de tiempo entre "no registrar" y "registrar" podría afectar el sistema de tal manera que los errores no ocurran. 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.
System.Diagnostics.Trace opera como parte de la colección DebugListeners y como tal se va tan rápido como el oyente más lento .. oyente El valor predeterminado escribe ya sea a la Debugger.Log (si se trata de la tala) o el sistema 'OutputDebugString '. Nota: a menos que necesite conectar múltiples oyentes a su salida de rastreo, Trace.WriteXX sigue siendo demasiado costoso de usar en situaciones de registro de alto rendimiento. Si debe escribir en la salida de depuración, debe llamar directamente a la función OutputDebugString en kernal32.dll. (al menos un 50% más rápido que Trace.WriteLine) – headsling
¿Qué pasa con TraceSource en v2 de System.Diagnosics? ¿Cómo funciona eso comparado con log4net? – Eatdoku