¿Cuál es el impacto en el rendimiento del rastreo en C# y ASP.NET?

Question

He encontrado esto en algún código de inicio de sesión de producción que estaba viendo recientemente ...

HttpContext.Current.Trace.Write(query + ": " + username + ", " + password)); 

... donde consulta es una consulta SQL corto para agarrar los usuarios que coinciden. ¿Tiene esto algún tipo de impacto en el rendimiento? Supongo que es muy pequeño.

Además, ¿cuál es el propósito de este tipo exacto de rastreo, utilizando el contexto HTTP? ¿A dónde se remonta esta información? ¡Gracias por adelantado!

Answer 1

Sí, tendrá un impacto en el rendimiento siempre que la constante de compilación condicional TRACE se defina durante la compilación. Hacer cualquier cosa tiene algún tipo de impacto :)

En cuanto a si esto tiene un impacto significativo en una aplicación. Es muy poco probable que Trace esté diseñado para ejecutarse y se ejecuta en muchas aplicaciones de producción. Solo un abuso de la característica debería llevar a una diferencia de rendimiento notoria.

Pero como siempre, no confíes en mí, confía en el generador de perfiles.

Answer 2

Los mensajes de seguimiento pueden ir a muchos lugares diferentes. Puede agregar (o eliminar) TraceListeners para la consola, la ventana de depuración de VisualStudio, los archivos o el registro de eventos, por nombrar algunos. Incluso puedes construir el tuyo propio.

Además, puede configurar Trace para que no haga nada cuando se compile para la versión.

Por lo tanto, el impacto en el rendimiento del uso de Trace puede variar mucho, desde cero hasta empantanar por completo su aplicación, dependiendo de qué oyentes estén activos. La mayoría de los oyentes, sin embargo, tienen el impacto que esperarías. Se necesita mucho trabajo para escribir en un archivo o base de datos o en la consola, y Trace no agrega tanta sobrecarga relativa a esas actividades vinculadas a E/S.

Answer 3

La mayor pérdida de rendimiento en este fragmento de código no está en la traza, sino en la concatenación de cadenas mediante el uso del operador +. Esto hace algunas operaciones de memoria ineficaces que pueden vencer una operación IO en términos de rendimiento. Lo cambiaría para utilizar algo como string.Concat o la clase StringBuilder (o string.Format para el caso).

Answer 4

Y si traza está escribiendo en un archivo de texto que va a costar más que escribir a la consola en mi humilde opinión

Answer 5

no tengo los puntos de reputación para comentarios, pero quería hacer una declaración breve sobre la respuesta de Jonathan. Los números que he visto parecen mostrar que no tiene sentido usar un generador de cadenas para un puñado de concatenaciones de cadenas. La sobrecarga de crear el objeto del generador de cadenas supera el beneficio de velocidad de concatenación.

Answer 6

Supongo que Trace Source observa el TraceLevel de su conmutador antes de reenviar los mensajes a los oyentes. Por lo tanto, si mantenemos el valor predeterminado de TraceLevel del switch en "Error", la sobrecarga de seguimiento se reduciría en gran medida, ya que solo los rastreos de "Error" se enviarían a los oyentes.

solo supongo ... aún no he medido nada. Se actualizará si lo hago.

2017 Update: parece ser una forma obsoleta pero bastante práctica de rastrear/registrar información en un navegador/página .aspx accesible de forma remota en una aplicación asp.net.

https://msdn.microsoft.com/en-IN/library/z48bew18(v=vs.71).aspx

Answer 7

"Rastreo implica una sobrecarga adicional a las solicitudes y no debe habilitarse para aplicaciones desplegadas. Trace.Write() declaraciones, sin embargo, se puede dejar en porque se ignoran cuando el rastreo no está permitido."

http://msdn.microsoft.com/en-us/library/ms972204.aspx