{"id":257172,"date":"2026-09-08T09:00:22","date_gmt":"2026-09-08T16:00:22","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/visualstudio\/?p=257172"},"modified":"2026-08-27T18:14:18","modified_gmt":"2026-08-28T01:14:18","slug":"today-i-will-find-hidden-latency-across-a-distributed-net-application","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/visualstudio\/today-i-will-find-hidden-latency-across-a-distributed-net-application\/","title":{"rendered":"Today I will… find hidden latency across a distributed .NET application"},"content":{"rendered":"

When a distributed application feels slow, the user sees one delay. The code behind that delay may run across a web frontend, backend services, databases, and external APIs. If you profile only the frontend while the backend is slow, the profiler can show that the frontend is healthy without revealing the actual bottleneck.<\/p>\n

This article shows how to narrow a cross-process performance problem with Visual Studio: identify the process that owns the slow operation, capture its CPU activity, inspect the report, and add a focused measurement when CPU samples cannot explain elapsed time. GitHub Copilot Profiler Agent reinforces this workflow with detailed analysis of the captured profile and helps validate the interpretation of the evidence.<\/p>\n

The case study uses the Interview Coach<\/a> sample, a .NET Aspire application with a Blazor frontend and several backend resources. The eventual cause is in an AI streaming path, but the investigation applies to any distributed .NET application where one user action crosses process boundaries.<\/p>\n

One symptom, several processes<\/h2>\n

The Interview Coach Web UI sends a prompt to a backend agent and renders the response as a stream of updates. I tested it with this prompt:<\/p>\n

Hi, I'm Peter. Here's my resume: https:\/\/justinyoo.github.io\/fake-resumes\/resume-peter-parker.pdf.\r\nAnd this is JD: https:\/\/justinyoo.github.io\/fake-resumes\/jd-cloud-solution-architect.pdf\r\n<\/code><\/pre>\n
The first complete response took roughly 1.5 to 2 minutes. Some of that time was expected: the first turn parses the PDF into Markdown and stores initial data in Cosmos DB. Even with that work in mind, the response felt slower than expected.<\/p>\n
One interaction crossed the Blazor Web UI, the agent, MCP servers, Cosmos DB, and a hosted model. Before looking for a slow method, I needed to establish which process was doing work and which process was waiting.<\/p>\n
Visual Studio’s Performance Profiler<\/a> was a good place to start.<\/p>\n
Define the question before collecting data<\/h2>\n
I reduced the investigation to two questions:<\/p>\n
    \n
  1. Which process owned the slow part of the interaction?<\/li>\n
  2. Once that process was isolated, was it computing or waiting?<\/li>\n<\/ol>\n
    AppHost starts the Web UI, agent, MCP servers, and data services as separate processes. A profile of InterviewCoach.AppHost<\/code> describes the orchestrator. It does not automatically describe the Blazor code in InterviewCoach.WebUI<\/code>.<\/p>\n
    CPU Usage can collect from multiple processes, which is useful for an initial system-wide view. Here, the visible slowdown occurred while the Web UI consumed and rendered updates, so I wanted a focused capture of that process. I kept the backend resources under Aspire and launched the Web UI as the Visual Studio profiling target.<\/p>\n
    Target the process that owns the work<\/h2>\n
    This walkthrough assumes the sample is configured for local Azure provisioning<\/a> and already runs successfully from Visual Studio.<\/p>\n
    Set InterviewCoach.AppHost<\/code> as the startup project, select its HTTPS launch profile, and choose Debug > Start Without Debugging<\/strong>. Starting without the debugger leaves AppHost running when the startup project changes later. Once the Aspire resources are ready, stop only the Aspire-managed webui<\/code> resource from the Aspire dashboard. Leave the agent and its dependencies running.<\/p>\n
    \"Aspire<\/p>\n
    \"Aspire<\/p>\n
    The standalone Web UI needs a launch profile that uses its own ports and points service discovery at the running agent. In this capture, the agent’s HTTPS endpoint used port 7048. Aspire can assign a different port after a restart, so use the value shown in the dashboard.<\/p>\n
    Add a Profiler<\/code> profile under profiles<\/code> in src\/InterviewCoach.WebUI\/Properties\/launchSettings.json<\/code>:<\/p>\n
    \"Profiler\": {\r\n  \"commandName\": \"Project\",\r\n  \"dotnetRunMessages\": true,\r\n  \"launchBrowser\": true,\r\n  \"applicationUrl\": \"https:\/\/localhost:7201;http:\/\/localhost:5088\",\r\n  \"environmentVariables\": {\r\n    \"ASPNETCORE_ENVIRONMENT\": \"Development\",\r\n    \"Services__agent__https__0\": \"localhost:7048\"\r\n  }\r\n}\r\n<\/code><\/pre>\n
    The Web UI addresses the agent through a logical service name:<\/p>\n
    client.BaseAddress = new Uri(\"https+http:\/\/agent\");\r\n<\/code><\/pre>\n
    The environment variable maps to Services:agent:https:0<\/code>. The configuration-based service discovery provider resolves localhost:7048<\/code> as the HTTPS endpoint for agent<\/code>. The value contains the host and port, not the https:\/\/<\/code> prefix.<\/p>\n
    In Visual Studio:<\/p>\n
      \n
    1. Set InterviewCoach.WebUI<\/code> as the startup project.<\/li>\n
    2. Select the Profiler<\/code> launch profile.<\/li>\n
    3. Set the build configuration to Release<\/code>.<\/li>\n
    4. Open Debug > Performance Profiler<\/strong>, or press Alt+F2<\/strong>.<\/li>\n
    5. Confirm that the target is InterviewCoach.WebUI<\/code>.<\/li>\n
    6. Select CPU Usage<\/strong>.<\/li>\n
    7. Select Start with collection paused<\/strong>.<\/li>\n<\/ol>\n
      \"Visual<\/p>\n
      Start the application. When the Web UI is ready, resume collection, submit the test prompt, and stop collection when the response finishes.<\/p>\n
      \"CPU<\/p>\n
      Read the CPU report before asking Copilot<\/h2>\n
      Start with the CPU timeline. Select only the interval from submitting the prompt to receiving the final update. This removes startup and unrelated activity from the details below the chart.<\/p>\n
      Next, open Call Tree<\/strong> and enable Just My Code<\/strong>. The columns answer different questions:<\/p>\n