Does System.Diagnostics.Trace have any performance degradation?

Question

I am looking for a simple proprietary solution for reporting .NET errors. I'm not interested in using log4net, Elmah or any other log library. Below I plan to use. My question is, the performance on my site is of the utmost importance and does this thread affect any performance issues?

Global.asax

protected void Application_Start(object sender, EventArgs e) { GlobalFilters.Filters.Add(new HandleExceptionsAttribute()); } 

Descriptor descriptor attribute:

 public sealed class HandleExceptionsAttribute : HandleErrorAttribute { private void TraceError(Exception _this) { Trace.TraceError("{0} Exception {1}", DateTime.Now.ToString("M/d/yyyy h:mmtt"), _this); } public override void OnException(ExceptionContext filterContext) { var ex = filterContext.Exception; TraceError(ex); Task.Run(() => { using (var msg = new MailMessage(ConfigurationManager.AppSettings["SendErrorsFrom"], ConfigurationManager.AppSettings["SendErrorsTo"])) { msg.Subject = ex.Message; msg.Body = ex.StackTrace; using (var smtp = new SmtpClient()) smtp.Send(msg); } }); } } 

web.config:

  <system.diagnostics> <trace autoflush="true" indentsize="4"> <listeners> <add name="textWriterListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="logs\log.txt"/> <add name="eventLogListener" type="System.Diagnostics.EventLogTraceListener" initializeData="Base Test" /> <remove name="Default"/> </listeners> </trace> </system.diagnostics> 

Answer 1

It depends.

TraceError uses the conditional compiler attribute, which means that if you compile the TRACE flag (as in RELEASE mode), then all TraceError calls will be removed from your compiled code. Allegedly, this would fix most of the performance problems for live code, because with maximum performance you are probably going to compile in RELEASE mode.

However, any additional code that is not actually found inside the TraceError call will still execute. Thus, in your case, the call to HandleExceptionsAttribute.TraceError() will be executed - it will immediately return without doing anything.

 // This code sticks around, and could still have performance implications. var additionalInfo = GoGetMoreInformation(); // This code disappears when compiled Trace.TraceError("Something went wrong: {0}", additionalInfo); 

And, of course, the other side is that you are not going to get any information from your tracks in live environments, where they can be very useful. In your case, this means that any exceptions thrown into your living system will be completely invisible to you. You will not have any indication that something is wrong if users do not complain about the results.

Correction

Apparently, what I said above is true for Debug , but Visual Studio will leave the TRACE flag active in default release mode.

Answer 2

Getting email for every exception? I wish you good luck with this.

The code, as it is, will not work. It's not about Trace.TraceError itself, but what you want to do. I sometimes saw error loops that throw millions of exceptions in a few minutes. You are working on a denial of service attack. Let's get some math. 1 million exceptions per minute with text blobs approx. 1,500 bytes over the network results in 1.5 GB / min of mail data. It will be a unit. 25 Mbps network bandwidth. And this is a conservative estimate. But if that happens, you will quickly run out of memory. An asynchronous approach to the task will queue the tasks. Since you will be sending emails slower than you can throw exceptions, you will get an OutOfMemoryException pretty soon, which you will also try to send by mail ... At the very least, you will quickly receive a free restart before the denial of service situation persists.

It would be best to write your own MailTraceListener, which will aggregate exceptions and reduce the speed of sent exceptions to mail, for example. no more than 1 / min. You can then add the RollingFileTraceListener (not part of .NET. There is a reason why there are external journaling logs) that will be written to a flat file, and you can send a summary summary by mail. It also makes sense to detect duplicate exceptions by their exception message so that only the summary is logged. For example. the first one is always registered, and then you check again that the last exception matches the new one. If so, add a counter and continue to do so until another appears. Then you can write a good summary that only 10 billion exceptions occurred, and you did not record any of them except the first.

Exceptions per se are slow. If you trace them or do not play any role. You can optimize the call to Trace, but this is your least problem. Unpacking the stack is the most expensive part of exception handling. The main achievement of tracking performance is a customized output device. You will find it pretty quickly if you have his profile.

As I said above, a good error handling strategy is not easy to implement, since you are dealing with exceptional cases where anything can happen. Including that your exception handling becomes part of the problem. You need to test this thoroughly, or you will find that it works fine if the error does not occur, but for some strange reason, it crashes when there is some kind of exception from around the corner.

Answer 3

For web applications, there is no reason to roll back your own - the infrastructure has the ability to notify you of any unprotected exception only through configuration, using ASP.NET health monitoring. See https://msdn.microsoft.com/en-us/library/Bb398933.aspx for a good start.

Also remember that the code you have will be ugly. What happens when the mail server is not configured correctly by throwing exceptions inside your exception handlers. Registration errors in case of malfunctions without increasing productivity is a non-trivial problem, therefore it is recommended to use a well-tested library, and not try to turn your own solution here.