I am working on the same issues. I am trying to use miniprofiler to trace microservice calls. The microservices are built using WebApi. Ideally I would want to have every microservice profile itself and return profiling information to the caller, and have the caller add the profile to it’s current operation. Also I would like the microservice profiles, when called by another service, to drop it’s profile results so they don’t show up on the originating request when they all run within the same web process.
The expected behavior is a request is made against an mvc page, the mvc page invokes an api gateway which contacts two different microservices to fulfill the request. The mvc page then shows a single profile on the page that has the profiles nested within it using steps. All the timings should be relative to the original request.
This system needs to work both when the calls are all in a shared site, or on separate machines. The communication is still expected to be HTTP or other out of process mechanism.
When the api/microservices profile for a “parent”, their local stores of profiles optionally won’t be appended with the current profile because it is expected to be stored in the parent. This prevents when it runs in the same process of showing duplicate calls.
@jnystrom I think you can do this using a persistent storage mechanism. I am not 100% sure on how to do this yet as it’s my next attempt at getting this to work. You would pass the current profile IDs to the API so that the API can add to the same storage mechanism that the rest client uses. MiniProfiler by default uses an in-memory store attached to HttpContext. Since they are not running within the same process they use different stores. This is why it is not seen in /mini-profiler-resources/results on the rest client. They will be found on your api under the same url.