Using native tracer on .NET 6+ app significantly impacts performance and scalability of Azure Function Isolated Worker w/ ASP.net Core Integration

[Justin Haygood]

Describe the bug
Inside an Azure Function .NET Isolated application, with the ASP.net Core integration (aka using the nuget package Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore in conjunction with "ConfigureFunctionsWebApplication"), which is the default when building an HttpTrigger application with the Azure Function SDK in .NET Isolated, performance is seriously hampered, to the point where it fails completely under load

To Reproduce
Steps to reproduce the behavior:

1. Open the attached project SampleAspNetCoreFunctionWorker.zip
2. Open Dockerfile and uncomment the 2 lines that start with CORECLR_PROFILER (it works when commented, hence the bug report over here and not in the Azure repo)
3. Build docker image with "docker build -t sample ."
4. Run built image with "docker run -p 7071:7071 -d sample
5. Run a load testing tool. I used bombadier with "bombardier -c 150 -n 2000 -l http://localhost:7071/api/Function1

Note: you can reproduce on Windows Azure Functions with the DataDog APM .NET extension as well, which isn't Docker based.

Expected behavior
Application works, and you get 2000 successful requests

Screenshots"

The top bombardier run is with the DD native ClrProfiler enabled, the bottom is with it disabled

Runtime environment (please complete the following information):

• Instrumentation mode: Docker container
• Tracer version: 2.49.0
• OS: Ubuntu 22 LTS (Microsoft standard Docker container)
• CLR: .NET 6 / Azure Function Runtime 4

Additional context
Note, this doesn't happen when using the raw Azure Function Worker HttpTrigger (aka taking HttpRequestData as input and returning HttpResponseData). It only happens when using the compatability API which returns IActionResult.