从 System.Net.Http.DelegatingHandler 调用时，MiniProfiler.Current 为 null

Question

我在我的 asp.net Web API 项目中使用迷你分析器，并希望跟踪在自定义 DelegatingHandler 中运行的某些代码的性能。

DelegatingHandler 内的调用 MiniProfiler.Current.Step() 不会显示在结果中。同一项目中的其他调用显示正常。

进一步调查显示，MiniProfiler.Current 是从WebRequestProfilerProvider 中的HttpContext.Current 检索到的。而HttpContext.Current 在从DelegatingHandler 调用时为空。

有没有更好的方法来检索 MiniProfiler.Current 以便它在处理程序中工作？

Answer 1

MiniProfiler Timings 默认存储在HttpContext.Current 中（如您所见）。因此，如果您从 HttpContxt.Current 为空的地方调用 MiniProfiler，则无法保存结果。解决方案是从其他地方保存（并检索）结果。

MiniProfiler 提供了更改所有结果的存储和检索位置的选项（使用MiniProfiler.Settings.Storage）。 new v3 MiniProfiler (beta nuget here) 提供了为每个请求配置不同的IStorage 的选项，以及使用MultiStorageProvider 指定可以存储和检索结果的多个位置。你可以在 github 上的 Sample.Mvc 项目中看到一个这样的例子。

在您的情况下，最好的方法可能是为您的全局 MiniProfiler.Settings.Storage 设置一个 MultiStorageProvider，它将首先从 HttpRuntimeCacheStorage 保存/检索，然后使用可从 @ 访问的其他 IStorage 987654334@。然后在DelegatingHandler 中，将MiniProfiler.Current.Storage 设置为仅使用您在MultiStorageProvider 中设置的第二个存储选项（因为尝试保存HttpCache 毫无意义）。在这种情况下，来自DelegatingHandler 的配置文件将保存到您的第二个存储选项中，并将与您的其他结果一起检索以供查看（因为MultiStorageProvider 将Load 从第一个位置获取结果，如果它在 HttpCache 中没有找到结果，会转到第二个选项。

注意 - 在这种情况下，拥有多个存储选项很有用，但它可能会对检索配置文件的性能产生负面影响。