The API I deployed on Net8 has a high traffic volume, so requests keep waiting. It will automatically disconnect after timeout,

[bbhxwl]

The API I deployed on Net8 has a high traffic volume, so requests keep waiting. It will automatically disconnect after timeout,
After several days of testing, my program is Net8 and runs on Docker. I am confident that Net8 cannot respond to a large number of requests and waits. However, my server's CPU, memory, and usage do not exceed 50%. Another Docker program on the same server has low concurrency and can respond normally. Therefore, the problem should be that one program cannot respond to too much data. There are about 200 requests per second, which is not too many. My CPU, memory, database, and usage are all relatively low.

How can I use Dotnet Monitor to analyze my Docker program? Where could the problem lie? Could it be that the thread pool is full or something like that? How to set it up?

[danroth27]

How can I use Dotnet Monitor to analyze my Docker program?

@noahfalk Is this something you can help out with?

[danroth27]

Since this doesn't appear to be a specific framework issue that we can take action on, I'm going to convert this to a discussion.

[noahfalk]

I can offer some suggestions but after this afternoon I'll be out on a long vacation so I'm probably not the best person to dig in.

I think a good first step will be determining if the requests are timing out because the server is slow to send a response, or some other issue is preventing the requests/responses from traveling across the network promptly. Although you could do this in a low tech way by enabling HttpLogging and looking at the console output, it takes some effort to interpret. A richer and more easily digestable approach if you don't already have a monitoring system is to use OpenTelemetry and the Aspire dashboard. The dashboard works standalone, no requirement that you use Aspire for your app. That tutorial will walk you through setting it up and everything there is free. A couple interesting notes:

• Step 2 of the tutorial is entirely optional. You don't need to add any custom telemetry.
• The http.server.request.duration metric should be very useful. It will tell you the latency distribution of your server responding to requests.
• You can see timelines for individual requests in the Traces part of the dashboard. If you also configure your test app that is generating requests to send telemetry to the same dashboard endpoint then both the client and server timings will show up in the same request timeline.

Assuming the requests are timing out because the server responds slowly, threadpool starvation is certainly one potential cause for that to occur that doesn't trigger high CPU usage. Other alternatives might be the request is slow because it is waiting on a slow database request, external web request or a lock. You can use the dashboard to pick some example slow request and look at its timeline in the Traces view or look at logs emitted by that request in the logs view which might give you a clear sign what is consuming the time. If there is nothing obvious you can also add your own logging to capture the time at various points. For threadpool starvation there is lots more info here how you might investigate that.

Hope that helps!