什么是 System.Web.Mvc.MvcHandler.ProcessAsyncRequest()？

发布于 2024-12-18 09:26:35 字数 586 浏览 1 评论 0原文

我正在 NewRelic 中进行一些跟踪，我发现几乎每个请求都包含对“System.Web.Mvc.MvcHandler.ProcessAsyncRequest()”的调用。

此函数调用可能需要 300 毫秒到 100 秒（说真的，100 秒）不等。我尝试搜索 msdn 文档，但 http: 上没有任何内容//msdn.microsoft.com/en-us/library/system.web.mvc.mvchandler.aspx

显然，这里有东西在骗我。

关于为什么需要这么长时间，我有一些理论：

类型推断？我正在使用结构图。
服务器资源问题？
.net 版本不兼容？
asp.net mvc 某种不兼容？

环境：

.net 4

asp.net mvc 3

专用虚拟机

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

感性 2024-12-25 09:26:35

当我发现这个问题时，我和@garfbradaz 的想法一样，并查看了 MVC 源代码。这很有趣，因为我发现没有引用 ProcessAsyncRequest 方法。

因此，我认为这可能是 New Relic 注入的东西，或者正如你所说，这是转移注意力的东西，有东西在欺骗我们！我关闭了 New Relic，并联系了他们的支持团队。

今天，在 New Relic 团队一位反应迅速且彬彬有礼的成员发了几封电子邮件后，他们回复了我并确认这是一个（某种意义上的）错误。以下是他们的回应：

ProcessAsyncRequest 是我们用于任何指标的自定义名称
记录不是/不继承自“System.Web.UI.Page”。
鉴于 MVC 视图引擎使用“System.Web.Mvc.ViewPage”所有这些
指标将错误地属于 New Relic 名称
“ProcessAsyncRequest。”
我将致力于修改代理和核心
希望能够汇总这些指标的仪器
适当地。对于由此带来的混乱和麻烦，我深表歉意
造成了你。
当我接近解决方案时，我会向您提供最新信息。

编辑：下面来自 New Relic 的进一步回复 - 看起来他们已经修复了。

我刚刚推送了一个提交，它将帮助我们更好地对
来自已安装代理的交易。
就性能问题而言，我们确实发现了报告的问题
AppHarbor 的出色工程师导致了 TypeLoadExceptions
这可能与缓慢加载/编译代码有关
缓存。我们已找到原因并处于最后测试阶段
该修复，我们希望在下一个版本中得到修复
代理。

New Relic 的 Nick 对此做出了出色的回应，他们的产品非常有用，所以我没有任何不好的感觉，只是想在这里分享详细信息。

很高兴发现我的 MVC 应用程序中没有幽灵！

目前，我对遇到这些问题的人的建议是关闭 New Relic，直到下一个版本发布。

编辑 2：New Relic 的 Nick 今天给我发了电子邮件 - 他们的最新代理（版本 2.0.9.15） - 现已可用，应该可以解决此问题。

When I found this issue, I thought the same as @garfbradaz and looked through the MVC source. It was interesting, as I found no reference to the ProcessAsyncRequest method.

Hence, I decided it might be something New Relic were injecting, or as you say, a red herring and something is lying to us! I switched New Relic off, and got in touch with their support team.

Today, after a few emails from an extremely responsive and courteous member of the New Relic team, they got back to me and confirmed it's a bug (of sorts). Here is their response:

ProcessAsyncRequest is a custom name that we use for any metric being
recorded that is not / does not inherit from "System.Web.UI.Page."
Given that MVC view engine uses "System.Web.Mvc.ViewPage" all of those
metrics will incorrectly fall under the New Relic moniker of
"ProcessAsyncRequest."
I will be working on a modification to the agent and the core
instrumentation that will hopefully aggregate these metrics
appropriately. I am sorry for the confusion and trouble this has
caused you.
I'll give you an update as I get close to a solution.

EDIT: Further response from New Relic below - looks like they have a fix in place.

I just pushed a commit that will help us better classify the
transactions coming from the installed agent.
As far as the performance issue we did discover an issue reported by
the awesome engineers at AppHarbor that was causing TypeLoadExceptions
which might be related to slow loading / compiling code being put into
the cache. We have found the cause and are in the final testing phases
of that fix and we are hoping to get the fix in the next release of
the agent.

Nick from New Relic was excellent in responding to this and their product has been really useful, so I don't have any bad feelings, just thought I'd share the details here.

Very happy to find out there are no ghosts in my MVC app anyway!

For now my advice to anyone having these problems is switch off New Relic until their next release.

EDIT 2: Nick from New Relic emailed me today - their latest agent (version 2.0.9.15) - is now available and should fix this issue.

回复收藏 0 原文