Azure托管Blazor应用长时间无响应，寻求排查方向指引

我们托管在Azure上的Blazor应用时常出现无响应情况（有时超过30秒）。查看Application Insights时发现请求始终处于等待状态：

目前无法确定具体在等待什么，怀疑是用户上传文件、生成docx/pdf这类耗时操作占用线程导致。我尝试用PerfView分析跟踪文件，通过JIT Stats View发现了几个耗时较长的函数：

但不清楚这些函数的具体信息、调用方以及耗时原因，相关堆栈跟踪文件包括trace1、trace2、trace3。

请帮忙指明排查方向？

排查方向建议 #

• 深挖PerfView调用链：放弃只看JIT Stats View，切换到Call Tree视图，按CPU耗时排序，定位耗时函数的完整调用链路，找到业务代码层的触发点。如果是JIT编译导致的耗时，可启用ReadyToRun预编译，发布时提前编译高频代码，降低运行时JIT开销。
• 排查同步阻塞：Blazor Server依赖SignalR，若主线程被同步耗时操作（比如文件上传、文档生成未用异步方法）阻塞，会导致所有请求排队。检查这类操作是否使用async/await异步模式，避免占用线程池线程。
• 排查Azure资源瓶颈：在Azure门户查看App Service的CPU、内存、磁盘IO监控指标，若资源耗尽（如CPU持续100%），会直接导致请求等待。可临时升级实例规格验证是否缓解问题。
• 分析AI依赖项跟踪：查看Application Insights的Dependencies面板，检查是否有外部服务（数据库、存储账户等）响应缓慢，导致应用等待外部调用返回。
• 隔离异步耗时操作：将文件上传、文档生成这类任务迁移到Azure Functions或后台服务异步处理，用Azure存储队列传递任务，应用仅负责接收请求和返回状态，避免阻塞主线程。
• 检查SignalR连接状态：Blazor Server无响应可能和SignalR连接中断/重连有关，查看AI的Exceptions和Traces面板，排查是否有SignalR相关的错误或超时日志。

内容的提问来源于stack exchange，提问作者Jeroen T