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:
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.