ASP.NET Core API - remove default logging providers to improve performance

So the basic point of this post is to tell you that ASP.NET Core applications have console logging on by default and you should disable that unless you really want that for some reason as it causes performance penalty. If you know how to do that then you may well skip reading this post beyond this point and check out my other posts, but if you didn't know this yet then read on.  

The ASP.NET Core provides four logging providers by default, namely Console, Debug, EventSource and TraceSource. You may or may not need these in your applications, so in case you just need to write logs to a file, database or something like that then better disable default ones. The next paragraph will show how doing that.

There are two ways to configure third-party logging provider in a .NET Core API application, Log4Net in my case. One way is to add the line "loggerFactory.AddLog4Net()" in your Startup.cs file as given in Log4Net plugin's github page and another is by using "ConfigureLogging" method in CreateHostBuilder method.  

Configure via Startup.cs file

Configure in Program.cs file

Now, as you can see in second screenshot clearing default providers is simple, you just need to call line logging.ClearProviders();

How much doing this helps?

To figure that out, I created, a default ASP.NET Core API project. Next I configured Log4Net using mechanisms, as shown in above two screenshots. Then I called both scenarios of API from a console application in a loop and recorded the time it took for 1000 executions. Below table shows how much difference in time was there between the two scenarios.

 Now if you measure "API hits per day", then this might not be of significance to you, but if it's "API hits per minute/second" then open your Visual Studio and remove unused providers ASAP. 

Happy Coding!!  

Web API complex input parameter is null

I do maintain a ASP.NET WebAPI 2.0 service that was running smoothly for quite some time on our production server, until one day an existing client of our service reported that they are getting "invalid request" response from our service and that behavior is random. So we checked our logs and found that request object we received from them were actually null and thus the error they got. Till this point our controller action looked like below: 

To diagnose this issue we added logs to check raw request received by us and that confirmed two things: 

1. First request received by was fine but every subsequent same request was landing in our action as null 

2. Raw request content and headers were similar for both successful and failed requests

Below is code that I used to log raw request content:

To sort out the issue we changed our action slightly. Now instead of letting framework to do model binding for us, we started doing it manually as shown in below snippet: 

Here we are reading request content as string and then converting it to our expected object using newtonsoft json converter. Hopefully this will help you to save some of your time.