2

We have an asp.net core 2 server. In performance tests, when we have a few (say tens of) pending requests, new CORS preflight requests stay pending.

It appears that asp.net core has a certain limit on the number of concurrent requests in pipeline, and the default value for that limit is very low.

Is there any resources about these performance related topics? Is there a way to prioritize requests?

Of course, after we optimize the other requests, this problem will get harder to reproduce, so we want to understand it well enough.

Alireza
  • 5,421
  • 5
  • 34
  • 67
  • 1
    Refreshing my memory, the [default kestrel options](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?tabs=aspnetcore2x) leave the max concurrent connections unlimited, and the CLR pool gets a [default max](https://github.com/dotnet/corefx/issues/15990#issuecomment-279023245) of 32K threads although can be changed [via config](https://github.com/dotnet/cli/issues/889) in your specific application. How are you hosting and testing the app? What does your request pipeline and middleware look like? – Daniel J.G. Oct 30 '17 at 09:43
  • @DanielJ.G. Mostly everything is default. We've added a logging middleware (custom implementation) and a jwt validation middleware. Thanks for the help, I guess I should de-register them to see if any of them is the cause. – Alireza Oct 30 '17 at 20:02

1 Answers1

3

I had answered a similar question related to benchmarking performance for ASP.NET Core Kestrel here.

In short, you could remove the middleware that is causing the bottlenecks, or at least this could help you diagnose the culprit.

Ordering
The order that middleware components are added in the Configure method defines the order in which they are invoked on requests, and the reverse order for the response. This ordering is critical for security, performance, and functionality.

------ Source: Microsoft Docs: ASP.NET Core Middleware

Short-Circuiting

You can short-circuit the request pipeline to handle performance optimizations (or testing) by not calling the next parameter. For example:

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        // make sure you place this at the top
        // the request pipeline will go in sequence
        app.Use(async (context, next) =>
        {
            // do work for your special case, performance tests, etc

            // in order to short-circuit the pipeline, do NOT call the next parameter 
            // so, you could place some kind of conditional here that will allow only
            // specific requests to continue down/up the pipeline
            if (!true)
            {
                await next.Invoke();
            }
        });

        // the rest of the pipeline
    }
}
Community
  • 1
  • 1
Svek
  • 12,350
  • 6
  • 38
  • 69
  • I'm profiling a real application. We need all lower levels to be engaged, all the way down to the database. – Alireza Oct 30 '17 at 10:08
  • 1
    @Alireza - I just updated the answer to give it more context to your requirement. I hope it makes sense. – Svek Oct 30 '17 at 12:37
  • Thanks for the answer. It is a very useful way to modify the pipeline to make some measurements. Just I don't see how can I use it in my scenario. We want the performance test to test the complete service, from the network wires to database disks. We don't want to bypass anything. – Alireza Oct 30 '17 at 20:07