locked
ASP.Net Core 3.1 API middleware for error hanling - bad performance? RRS feed

  • Question

  • User-50787436 posted

    Hi all, I have an API in ASP.Net Core 3.1 written in a standard clean architecture way (with the API project, Application/Domain and Infrastructure). At infrastructure level, it performs calls to other APIs, and depending on the output (case by case) we throw special exceptions that are caught on an error handling middleware, that transforms them to special http result codes.

    A quick sample of the middleware:

    public static void UseExceptionHandler(this IApplicationBuilder app, ILogger logger, IConfiguration configuration)
            {
                app.UseExceptionHandler(appError =>
                {
                    appError.Run(async context =>
                    {
                        var contextFeature = context.Features.Get<IExceptionHandlerFeature>();
    
                        var code = HttpStatusCode.InternalServerError; // 500 if unexpected
                        var exception = contextFeature?.Error;
                        string error = "";
    
                        switch (exception)
                        {
                            case RequestValidationException _:
                                {
                                    code = HttpStatusCode.BadRequest;
    
                                    RequestValidationException ex = ((RequestValidationException)exception);
    
                                    error = exception.Message;
    
                                    break;
                                }
    
                            case PreConditionException _:
    
                                code = HttpStatusCode.PreconditionFailed;
    
                                error = exception.Message;
    
                                break;
    
                            case OperationCanceledException _:
                            case TimeoutException _:
    
                                code = HttpStatusCode.GatewayTimeout;
    
                                error = exception.Message;
                                break;
    
                            default:
    
                                code = HttpStatusCode.InternalServerError;
    
                                break;
                        }
    
                        context.Response.StatusCode = (int)code;
                        context.Response.ContentType = "application/json";
    
                        await context.Response.WriteAsync(error);
                    });
                });
            }

    This API is not live yet, and we didn't perform any performance tests as well.

    On a "coffe" conversation without any proof, someone told us that this would cause significant performance issues in live environments when many operations happen at the same time.

    I find it quite strange, but I don't have any evidence that it will create any issues, and don't have any that it won't.

    So I'd like to know what you guys that have APIs with similar scenarios how are your APIs doing live, and if you use something like this, or if you use anything else that performs better than this that I should be aware of.

    I'm aware that we can use a filter instead of the middleware, but at the end of the day my guess is the overall performance should be pretty must the same right?

    Or is there any alternative on this? I mean, if at infrastructure level I receive an error from the API I'm calling and I want my consumer to receive a bad request, what's the alternative?

    Thanks a lot.

    Friday, November 13, 2020 10:29 AM

Answers

  • User-474980206 posted

    there is nothing in your code to lead to the suggestion. it ties into existing middleware, and is only executed on an error. 

    also a filter is executed by middleware. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, November 13, 2020 10:31 PM

All replies

  • User1120430333 posted

    I would advise you to do some kind of load testing and use a .NET performance tool.

    Friday, November 13, 2020 3:47 PM
  • User-50787436 posted

    Thank you, we are not at that stage yet. I was hoping to get feedback from someone who had a similar need and used the same strategy or another that could suit better this scenario.

    In fact, at the moment I don't have any evidence of this being a problem (or not), but knowing in advance is always better than finding it out later, and we are still in development. This piece in particular is growing up...

    Friday, November 13, 2020 5:48 PM
  • User-474980206 posted

    there is nothing in your code to lead to the suggestion. it ties into existing middleware, and is only executed on an error. 

    also a filter is executed by middleware. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, November 13, 2020 10:31 PM