背景：我有一个 ASP.NET Core 应用程序并有一个 API 方法，该方法采用前端已上传到 Azure Blob 的 blob 的文件名。然后它需要创建 Blob 的缩略图版本并返回新上传的缩略图 Blob 的名称。有时，对于完全相同的文件大小，最多可能需要 40 秒才能完成。大多数情况下，大约是 400 毫秒。
以下是 App Insights 的端到端，我有一些不明白的地方：
1) 请求持续时间为 37.5 秒，但其他操作加起来远不及这个时间
2) 为什么会调用主数据库？我们在多个上下文中使用 EF6
3) 该应用正在使用 Azure 应用服务和 SQL Azure。我不明白为什么响应时间如此不一致。
【问题讨论】：
标签： asp.net entity-framework azure asp.net-core azure-blob-storage
我多次注意到，在将应用程序部署到 Azure 后的第一个请求或在很长一段时间内没有向应用程序发出请求后，获得响应所需的时间要长得多。 据我所知，这与网站的启动时间有关（如果您在基于 Windows 的底层 VM 上使用 App Service > 它仍然使用 IIS 作为反向代理）。
我通过配置偶尔向应用执行请求的运行状况检查解决了这个问题。
此外，除了 Application Insights（仅在应用程序启动后记录信息）之外，您还可以尝试here 列出的工具以查看更多信息。
希望对你有帮助！
【讨论】：
1.
请求时间线的显示方式只为您提供整个请求的时间跨度（37.5 秒）和每个依赖项的各个时间跨度。
依赖项是另一个将其运行时发送到应用程序洞察力的调用。 在您的示例中，对数据库的每次调用都会自动跟踪为依赖项。每次数据库调用后运行的代码都不是。
例如请求一个需要 200 毫秒的数据库条目，然后发出一个 2 秒的 Thread.Sleep 并请求另一个需要 300 毫秒的数据库条目，这将导致两个数据库调用依赖项之间出现 2 秒的间隙，这两个依赖项将分别以 200/300 毫秒列出。
您可以使用TelemetryClient.TrackDependency 将您自己的部分代码包装到它自己的依赖项中。这样，您将在请求时间线上看到自己的代码作为条目。
2.
根据您的 EntityFramework 数据库初始化器，EF 将在创建上下文时连接到主数据库。 （例如，如果数据库不存在，则创建数据库）。
3.
尝试跟踪您自己的代码以找出其中的哪些部分运行缓慢。 EF 有一些性能issues 需要考虑，尝试了解您使用的库的性能警告。如果您的调用速度一直很慢，则可能是资源被过度使用或缓存过早清空的问题（例如 EF 暖查询与冷查询）。
【讨论】：