0

Under an 'apps' web site, we've created a web application through docker/powershell using:

New-WebApplication -Name 'service_b' -Site 'apps' -PhysicalPath 'C:\ServiceB.API' -ApplicationPool 'DefaultAppPool'.

With SignalFx tracing enabled, we notice a very long, unexplainable delay when IIS or WebAPI seems to redirect from a path that includes the web application name /service_b/api/1.0/users/status to the path that lacks the web app name api/1.0/users/status, and we have no idea what it's doing during this seemingly pointless step:

enter image description here

I don't think the request is leaving the application server. What exactly is IIS/WebAPI doing during this step? Perhaps the request is being reordered to the back of a queue and treated as a new request? This all occurs before any of the application code runs, which we know because the 'Auth' logic -- the very first thing to run -- doesn't even start after the 1.74 second delay, which seems to be consumed by some kind of internal IIS/WebAPI routing.

Note: ServiceA is another application with tracing enabled that's making a REST call to ServiceB. The call reaches ServiceB very quickly in just a few microseconds, so the 1.74s delay happens after ServiceB has already received the request and started clocking its own tracing span.

Triynko
  • 18,766
  • 21
  • 107
  • 173
  • Similar question that might be somewhat related: https://stackoverflow.com/questions/55124938/asp-net-core-middleware-routing-delay-between-request-and-action – Triynko Nov 03 '21 at 15:54
  • Try to use failed request tracing to check what happened during the IIS/WebAPI routing. – Bruce Zhang Nov 04 '21 at 07:04
  • The requests aren't failing, so I don't think failed request tracing would help. I'm concerned that the delay is simply a .NET ThreadPool issue where IIS hands off the request to the ThreadPool, but it's already saturated with other concurrent requests, as well as their async continuations, so it's not fairly progressing requests and getting I/O operations started early enough; it's favoring already-running requests and their continuations at the expense of getting other requests in the pipeline started sooner. – Triynko Nov 09 '21 at 14:38

0 Answers0